Strange math library results on i386-linux

[Brad Lucier <lucier at math dot purdue dot edu>]

There is a strange interaction going on between glibc and gcc 3.2
on Red Hat Linux 7.3 for i386.

Gaston Gonnet has put together some tests of the math library functions at

http://www.inf.ethz.ch/personal/gonnet/FPAccuracy/Analysis.html

He used -O3 as the default compiler flags and got what I considered to
be surprisingly bad results.  So I ran his experiments with various
compiler flags and put the results at

http://www.math.purdue.edu/~lucier/fun-test/

Indeed, when I compiled his tests using -O0, the results were quite (very)
good, except for sin, cos, tan (for lack of perfect argument reduction)
and j0, j1, gamma, lgamma, y0, and y1 (that I don't really care about for the
moment, they seem all to have to do with argument reduction and/or handling
of results close to the maximum flonum).  

There is a double-rounding effect going on for 1.0/x and Pi*x, so I
also ran the tests after setting the default rounding precision to double
precision rather than extended precision.  This fixed these two tests,
but made the other tests quite a bit worse.  OK, I think, perhaps the glibc
routines were written assuming that the rounding precision is extended
precision (and, if so, why don't they make sure the rounding precision
is extended precision when they execute?).  So I went on my merry way
and ran the tests with -O1, -ffast-math (perhaps it would use the built-ins
then), -ffloat-store (would this help?), etc.

Overall, the results suck except for -O0 in extended precision.  They are
particularly bad for -O1 with the default rounding precision set to 64
bits, which happens to be what I use to compile my main application.
(Gambit-C Scheme has precise I/O routines for double-precision numbers, and the
algorithms it uses require 64-bit rounding precision.)

So, do you people have any suggestions about how to fix or lesson these
problems?  I often defend attacks on gcc's floating-point code generation
when these attacks are based on erroneous expectations or understandings,
but I can't see any way to defend this behavior.

Brad