More wrong math results w/ inline

[Kurt Garloff]

Here is an example for more wrong math results:

garloff@kg1:/home/garloff/C > egcc -O2 -o bug_math bug_math.c -lm
garloff@kg1:/home/garloff/C > bug_math 42 12 288 372.94964; bug_math
5.7718313756965, 4.885604e+00
5.7718313755102, 4.885604e+00

Here are correct results:

garloff@kg1:/home/garloff/C > egcc -o bug_math bug_math.c -lm
garloff@kg1:/home/garloff/C > bug_math 42 12 288 372.94964; bug_math
0.8862269255100, 5.720524e-11
0.8862269254528, 2.109424e-15
garloff@kg1:/home/garloff/C > egcc -O2 -o bug_math bug_math.c -lm -fno-inline
garloff@kg1:/home/garloff/C > bug_math 42 12 288 372.94964; bug_math
0.8862269255100, 5.720535e-11
0.8862269254528, 2.109424e-15

egcs/gcc-28/gcc-27 all behave the same. Ughh !
(Machine: 6x86, Linux-2190, glibc-206, egcs-980315)

Inlining of math functions seem to produce this. Is it a problem of the
small ix86 FPU stack? -ffloat-store fixes the problem as well as -O3 or
-fno-inline.

Sourcecode is appended. (It is an implementation for the gamma function.)

I hope this can be fixed soon. Otherwise I have to recompile everything w/o
inlining to be sure to get the correct math results from my numerical
simulation code. I fear this would drop performance by a factor of 3.

-- 
Kurt Garloff, Dortmund 
<K.Garloff@ping.de>
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff