This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



------- Comment #4 from rob1weld at aol dot com  2007-06-03 16:05 -------
I copied
gcc-4_3-build/i686-pc-linux-gnu/libjava/classpath/native/fdlibm/.libs/libfdlibm.a
to my current directory and instead of using "-lm" I used "./libfdlibm.a" ...

Guess what.


I propose this simple and useful fix:

We need to re-arrange gcc to build a directory like
"gcc-4_3-build/libdecnumber" and "gcc-4_3-build/prev-libdecnumber" called
"gcc-4_3-build/libfdlibm" "gcc-4_3-build/prev-libfdlibm".

The first pass can build it using "-O0" so it is certain to work (or we must
fix that) and the next pass can build it with profiling and "-O3" enabled. 

Profiling works on 4.2.0 (but not on 4.3.0). A message can be printed that if
profiling the math library fails to rebuild by typing "make nomathprofile".

The third pass can use the profiled information to build the math library in a
fully optimized state.

The resulting super-optimized math library can then be used for the libjava
library in the fourth "library build pass" and any other language that wants to
take advantage of this. 

No effort would be wasted and we would have a fast / accurate library that
works on all platforms - OR is the libfdlibm not a good plan and should be
removed from libjava?


If you have this page on your computer look at
/usr/share/doc/glibc-2.5/manual/libc/Errors-in-Math-Functions.html - it is
created when you compile libc6.

That page is a report of the libc6 tests that are ran when the code is built
and shows the resulting errors for every function (as is suggested in IEEE754).


It looks like this (edited for brevity):

The table lists the ULP values for different architectures. Different
architectures have different results since their hardware support for
floating-point operations varies and also the existing hardware support is
different. 

Function  Alpha  Generic  ix86  IA64  PowerPC 

acosf      -      -        -     -     - 
acos       -      -        -     -     - 
cosf       1      -        1     1     1 
cos        2      -        2     2     2 
cosl       -      -        1     1     1  
logl       -      -        -     -     1 
log10f     2      -        1     1     2 
log10      1      -        -     -     1 
log10l     -      -        1     1     1  
powl       -      -        -     -     1  
...


Since we link some of gcc with "-lm" and some with libfdlibm we have an
inconsistant math library upon which gcc is based. We can standardize and test
our math library to provide the same (correct) result on all platforms (as IEEE
754 requires).

Lets remove "-lm" from gcc and use libfdlibm on as many platforms as is
possible, where that doesn't work we simply let them use "-lm", like they did
before, and they will be no worse off. The rest of us will be much better off.


-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]