This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Strange math library results on i386-linux
> 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.
Adding the defines is definitly good idea. Other problem with inline
math routines is the lack of support for SSE so with -mfpmath=sse the
code is extremly slow. I did some work on this and I need other defines
to distinguiwh this, I sent patch for that.
Several parts of mathinling needs guarding by different define than
OPTIMIZE, if someone more aware of the problematic can prepare list, it
can be cool.
Concerning the IBM routines, we did some testing for Athlon and they are
loss, at least overall for floor/sin/cos calls.
>
> 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.
I think 80bit rounding is considered to be part of Linux API.
I agree that this is ugly, but also it is dificult to change it, as
checking control word in each FP library call is extremly expensive.
Perhaps we can cache the value of control word in the memory to optimize
it.
Honza
>
> Brad