Re: Strange math library results on i386-linux

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

> > 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).
> 
> I wonder if you could also add directories to your ~lucier/fun-test/
> pages, that show the effects of -D__NO_MATH_INLINES.  Looking at
> glibc's headers there are a number of intrinsics that are inlined
> by "#ifdef __OPTIMIZE__" that may need to guarded by "#ifdef
> __FAST_MATH__", which might explain some of the loss of precision
> between -O0 and -O1.

Fecking brilliant.  With this define, there is no difference between the
-O0 and optimized results; on the whole the linux results are
better than on Solaris (except for Solaris's perfect argument reduction for
sin/cos/tan).  The results are again at

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

So now I see why -fno-math-errno and -funsafe-math-optimizations should
have associated DEFINEs.  If there were -D__NO_MATH_ERRNO, then sqrt
could be inlined even if -D__NO_UNSAFE_MATH_OPTIMIZATIONS (since the
hardware sqrt is exact in IEEE 754 arithmetic implementations).  The
other hardware implementations of libm routines could be used with
-D__NO_MATH_ERRNO if they were as accurate, etc., as the glibc routines,
even if they don't set errno.

I suppose one should investigate why the linux libm routines do not ensure
that the rounding precision is set to extended precision for the bodies of
those routines, since many of them evidently require it.

Brad