Hi all, I have just submitted a patch emitting some new floating-point code from the Fortran front-end, improving our IEEE support there: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02444.html
However, in one of the cases where we emit a call to __builtin_remainderf(), we
get wrong code generation on i386. It is peculiar because:
- the wrong code occurs at all optimization levels, and the following flags
(any or all) do not affect it: -mfpmath=sse -msse2
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans
- the wrong code does not occur with -ffloat-store
- the code generate looks fine by every aspect I could try. I could not
generate a direct C testcase, unfortunately, but it is equivalent to:
D.2303 = __builtin_remainderf (ieee_value_4 (&C.2299, &D.2301),
1.0e+0);
where ieee_value_4() is a function that returns a positive infinity (for the
specific values of arguments passed). However, if I split it in:
x = ieee_value_4 (&C.2289, &D.2293);
D.2297 = __builtin_remainderf (x, 1.0e+0);
then the wrong result does not occur anymore either. What’s bugging me is that,
with and without -ffloat-store, the same dump trees are generated. So I don’t
know how to get further on debugging this. I do think it’s something wrong with
the expansion of __builtin_remainderf(), especially as it depends on
-ffloat-store.
I attach the source code triggering it (built on trunk with my patch at
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02444.html), the tree dumps, and
the assembler outputs (a.s without -ffloat-store, and a.s.floatstore with it).
I can clearly see, from the assembly diff, that something is indeed changing
but I cannot understand what.
Thanks in advance if you have any hint to share, or get a minute to look at the
dumps/assembly.
FX
a.f90
Description: Binary data
a.f90.003t.original
Description: Binary data
a.f90.174t.optimized
Description: Binary data
a.s
Description: Binary data
a.s.floatstore
Description: Binary data
