home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / unix / bsd / 11121 < prev    next >
Encoding:
Text File  |  1993-01-11  |  2.7 KB  |  80 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!munnari.oz.au!metro!ipso!runxtsa!bde
  3. From: bde@runx.oz.au (Bruce Evans)
  4. Subject: Re: [386bsd] gcc 2.3.2/2.3.3 compile solution
  5. Message-ID: <1993Jan11.091833.16806@runx.oz.au>
  6. Organization: RUNX Un*x Timeshare.  Sydney, Australia.
  7. References: <1993Jan08.184051.5674@mav.com> <1993Jan10.223405.23735@zia.aoc.nrao.edu>
  8. Date: Mon, 11 Jan 93 09:18:33 GMT
  9. Lines: 69
  10.  
  11. In article <1993Jan10.223405.23735@zia.aoc.nrao.edu> cflatter@nrao.edu writes:
  12. >In article 5674@mav.com, rick@mav.com (Hendrik Groeneveld) writes:
  13. >>
  14. >>The problem is not a floating constant out of range. The problem
  15. >>is a floating point stack overflow. To get passed this, manually
  16. >>compile fold-const.c using -S in place of -c. Edit fold-const.s
  17. >>and replace "fsts" with "fstps" in _real_value_truncate. Then
  18. >>assemble (as -o fold-const.o fold-const.s). 
  19. >
  20. >I didn't get this problem but I have had problems with the macro DBL_MAX.
  21.  
  22. I think the "fstps" bug was the main 386-related bug fixed in gcc-1.40.
  23.  
  24. >It turns out that the values of DBL_MAX and DBL_MIN are one digit too
  25. >short in /usr/include/float.h: this is a problem since DBL_MAX is
  26. >rounded to the next highest digit and is therefore larger than the
  27. >maximum representable double...
  28.  
  29. The problem is inaccurate rounding (in atof()) more than the lack of
  30. digits.
  31.  
  32. >#define DBL_MAX         1.7976931348623157E+308
  33.  
  34. The correct rounding of the last three digits is 159, not 157.  I'm
  35. not sure what should happen when either of these is rounded to 160
  36. and the last 0 is dropped.  The dropped digit is really beyond the
  37. precision available, so maybe atof/scanf should round the number
  38. down to DBL_MAX.
  39.  
  40. In any case, float.h should have a value that works, not necessarily
  41. a value that is correctly rounded.  The above doesn't work either.
  42. Look at how it gets munged further by gcc's output routine (printf) and
  43. by gas:
  44.  
  45. foo.c:
  46.     double x = 1.7976931348623157E+308;
  47.                    ^^
  48. foo.s:
  49.     ...
  50.     .double 1.7976931348623168000eE+308;
  51.                 ^^
  52. foo.o:
  53.     02 00 00 00 00 00 00 F0 7F
  54.  
  55. This is a NaN (as printf will tell you).  DBL_MAX is
  56.  
  57.     FF FF FF FF FF FF FF EF 7F
  58.  
  59. while +Infinity is
  60.  
  61.     00 00 00 00 00 00 00 F0 7F
  62.  
  63. gas apparently has bugs too.  It should produce +Infinity.  I think it is
  64. OK internally but it may be trusting the library too much.  gcc can easily
  65. be changed to avoid printf for output, but input is harder.
  66.  
  67. One value that works is
  68.  
  69. #define DBL_MAX         1.7976931348623147E+308
  70.                     ^ was 5
  71.  
  72. gcc prints 58 for the last two digits and gas converts the number correctly.
  73. Printing the number then puts 68 in the last 2 digits...
  74.  
  75. All this is for the stock 386BSD-0.1 gcc and gas binaries.  Partial fixes
  76. could easily make the problem worse.  (I made one to improve the accuracy
  77. of atof() in 0.1 :-().
  78. -- 
  79. Bruce Evans  (bde@runx.oz.au)
  80.