Date: Tue, 6 May 1997 08:29:03 +1000 From: Bruce Evans <bde@zeta.org.au> To: griepent@wias-berlin.de, helbig@MX.BA-Stuttgart.De Cc: bugs@FreeBSD.ORG Subject: Re: Underflow floating point exceptions under FreeBSD 2.1.5 Message-ID: <199705052229.IAA13790@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> To stay compatible with an institute I want to use a numerical >> package written in ANSI-C which works flawlessly on DEC and SGI machines. >> I was able to compile (gcc-2.6.3) the package on several Intel >> platforms (from 486 DX to PentiumPro) under FreeBSD-2.1.5. >> >> Trying to run it there always occured strange underflow floating >> point exceptions in code fragments computing mathematical >> functions like >> >> sqrt, cos, log >> >> with harmless arguments of type double in the range of 1.0e-20 to 1.0e+20, >> which should be normally no big deal in the IEEE 754 world! Underflow exceptions are probably normal, but can't be detected in ANSI C. FreeBSD does not trap on underflow. FreeBSD-2.1.5 has several serious bugs in the non-default i387 version of libm. These usually cause invalid operand (stack overflow) exceptions and traps, not underflow. All of the known ones are fixed in FreeBSD-2.1.7 and FreeBSD-2.2.1. FreeBSD has several bugs in the float-precision functions. Half of the known ones are fixed in FreeBSD-2.2.1. >> recompile the libm sources with no optimization! >> >> Again building the package with that math library the code is running now >> and we get the same numerical results and performance as on the DEC or SGI >> machines! The difference may have been caused by a compiler bug, or by changing the FreeBSD default precision of 53 bits. Gcc does several optimizations related to calculating constant expressions at compile time. This breaks IEEE'ness although not ANSI'ness. I use the following kludge to avoid some of the optimizations: --- diff -c2 math_private.h~ math_private.h *** math_private.h~ Sun Feb 23 22:48:03 1997 --- math_private.h Sun Feb 23 22:49:08 1997 *************** *** 21,24 **** --- 21,31 ---- #include <sys/types.h> + /* + * Gross hack to avoid compile time optimizations that break IEEE-ness. + */ + #ifdef __GNUC__ + #define const volatile const + #endif + /* The original fdlibm code used statements like: n0 = ((*(int*)&one)>>29)^1; * index of high word * --- >> (1) Let me assume that the original libm shared library was compiled >> also with the gcc-2.6.3 compiler. >> Is there a (known) optimization bug in the gcc-2.6.3 compiler? > >Your assumption is correct. And there are known (and unknown :-) ) optimization >bugs in gcc-2.6.3. That's why virtual all system software in FreeBSD >is compiled with the lowest "optimization" flag -O and not with the even >buggier -O2 etc. -O2 is probably not important here. The i386 version of gcc has many known bugs related to floating point precision. Don't expect to get IEEE exact results in all cases. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705052229.IAA13790>