[Bug rtl-optimization/323] optimized code gives strange floating point results

[David dot Monniaux at imag dot fr]

------- Comment #124 from David dot Monniaux at imag dot fr  2008-11-11 07:46 -------
Vincent Lefèvre is right: the issue is quite subtle. (I should mention that
Vincent is an expert in computer arithmetics, which I'm not.)

As he rightly points, conformance to IEEE-754 should be evaluated for a whole
software/hardware system - it is possible to have a IEEE-754 system entirely
implemented in software.

It seems like the C99 standard prohibits double rounding, and prohibits having
values depend on the vagaries of register spilling. Except that this
prohibition is explicit only in non-normative sections. "Language lawyers" have
sent me justifications that this prohibition is implied by various normative
prescriptions of the standard.

I think that in any case we should not spend too much energy trying to assign
blame (who conforms to the standard) but rather try to find solutions.

The short answer is that no compiler, be it gcc, will be modified so that
complex sequences of operations are used for floating-point operations in lieu
of directly using x87 instructions! At least for two reasons:
* x87 is now fading away (its use is deprecated on x86-64, it's not used by
default on Intel Macintosh...)
* Most people don't want to pay the performance hit.

In addition, I think there are more urgent things to fix in gcc's
floating-point system, such as support for #pragma STDC FENV ACCESS

Now for some additional facts:
* It is possible to force the x87 to use reduced precision for the mantissa
(with inline asm or even now with gcc options).
* This setting does not affect the range of exponents. so you can still have
surprises if a very tiny nonzero value is kept in a register then is rounded to
zero when spilled to memory.
* In some rare cases, you can have "double rounding on underflow": you get a
different result by computing on SSE in double precision mode on the one hand,
and by computing on x87 in "double precision" then writing to a double variable
in memory.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323