[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor

["rob1weld at aol dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #2 from rob1weld at aol dot com  2007-06-03 13:16 -------
Did GSL and Paranoia with -ffloat-store for gcc 4.3.0, same result.

Instead of "the normal x87 issue" it might be a "libm issue" since it works
with Cygwin's gcc but fails with all the Linux gcc's.


Here is something that gsl configure prints:

checking for inline... inline
checking for extern inline... yes
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking for vprintf... yes
checking for _doprnt... no
...
checking for cos in -lm... yes
checking whether feenableexcept is declared... yes
checking whether fesettrapenable is declared... no
checking whether hypot is declared... yes
checking whether expm1 is declared... yes
checking whether acosh is declared... yes
checking whether asinh is declared... yes
checking whether atanh is declared... yes
checking whether ldexp is declared... yes
checking whether frexp is declared... yes
checking whether isinf is declared... yes
checking whether finite is declared... yes
checking whether isfinite is declared... no
checking whether isnan is declared... yes
checking whether log1p is declared... yes
checking for long double stdio... yes
checking for extended floating point registers... yes
checking for IEEE arithmetic interface type... gnux86
checking for FPU_SETCW... yes
checking for IEEE compiler flags... none
checking for IEEE comparisons... yes
checking for IEEE denormalized values... yes
...

When Cygwin builds gcc it answers yes to these questions:
checking ieeefp.h usability... no
checking ieeefp.h presence... no

It is good to see that GSL check the need for FPU_SETCW. 

GSL, like GCC, uses "-lm" whereas GCC's libjava builds and uses it's own
libfdlibm.a (but unfortunately _seems_ to use "-lm" in a few places).


If these programs CAN be compiled on target i686-pc-cygwin (old gcc) WITHOUT
errors and can NOT be compiled on target i686-pc-linux-gnu (newer gcc) WITHOUT
errors then NEWER gcc is not implementing it's math with the same accuracy as
the older gcc does. 

I am using the same computer to run both tests so, in theory, it would be
possible to alter GCC 4.3.0 (and 4.2.1, etc.) so that it's math results were as
accurate as they once were.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180