Return to BSD News archive
Received: by minnie.vk1xwt.ampr.org with NNTP id AA6396 ; Sat, 09 Jan 93 02:06:37 EST Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde From: bde@runx.oz.au (Bruce Evans) Subject: Re: [386bsd] gcc 2.3.2/2.3.3 compile solution Message-ID: <1993Jan11.091833.16806@runx.oz.au> Organization: RUNX Un*x Timeshare. Sydney, Australia. References: <1993Jan08.184051.5674@mav.com> <1993Jan10.223405.23735@zia.aoc.nrao.edu> Date: Mon, 11 Jan 93 09:18:33 GMT Lines: 69 In article <1993Jan10.223405.23735@zia.aoc.nrao.edu> cflatter@nrao.edu writes: >In article 5674@mav.com, rick@mav.com (Hendrik Groeneveld) writes: >> >>The problem is not a floating constant out of range. The problem >>is a floating point stack overflow. To get passed this, manually >>compile fold-const.c using -S in place of -c. Edit fold-const.s >>and replace "fsts" with "fstps" in _real_value_truncate. Then >>assemble (as -o fold-const.o fold-const.s). > >I didn't get this problem but I have had problems with the macro DBL_MAX. I think the "fstps" bug was the main 386-related bug fixed in gcc-1.40. >It turns out that the values of DBL_MAX and DBL_MIN are one digit too >short in /usr/include/float.h: this is a problem since DBL_MAX is >rounded to the next highest digit and is therefore larger than the >maximum representable double... The problem is inaccurate rounding (in atof()) more than the lack of digits. >#define DBL_MAX 1.7976931348623157E+308 The correct rounding of the last three digits is 159, not 157. I'm not sure what should happen when either of these is rounded to 160 and the last 0 is dropped. The dropped digit is really beyond the precision available, so maybe atof/scanf should round the number down to DBL_MAX. In any case, float.h should have a value that works, not necessarily a value that is correctly rounded. The above doesn't work either. Look at how it gets munged further by gcc's output routine (printf) and by gas: foo.c: double x = 1.7976931348623157E+308; ^^ foo.s: ... .double 1.7976931348623168000eE+308; ^^ foo.o: 02 00 00 00 00 00 00 F0 7F This is a NaN (as printf will tell you). DBL_MAX is FF FF FF FF FF FF FF EF 7F while +Infinity is 00 00 00 00 00 00 00 F0 7F gas apparently has bugs too. It should produce +Infinity. I think it is OK internally but it may be trusting the library too much. gcc can easily be changed to avoid printf for output, but input is harder. One value that works is #define DBL_MAX 1.7976931348623147E+308 ^ was 5 gcc prints 58 for the last two digits and gas converts the number correctly. Printing the number then puts 68 in the last 2 digits... All this is for the stock 386BSD-0.1 gcc and gas binaries. Partial fixes could easily make the problem worse. (I made one to improve the accuracy of atof() in 0.1 :-(). -- Bruce Evans (bde@runx.oz.au)