[Bug rtl-optimization/323] optimized code gives strange floating point results
------- Comment #125 from vincent at vinc17 dot org 2008-11-11 10:13 -------
(In reply to comment #124)
> It seems like the C99 standard prohibits double rounding,
only if Annex F is claimed to be supported (note: Annex F is not just IEEE 754,
it also contains specific bindings). IEEE 754 doesn't prohibit double rounding
either (this depends on the bindings), but with C99 + Annex F, double rounding
is prohibited.
Now, bug 323 is not about double rounding specifically. There are two potential
problems:
1. A "double" variable (or result of a cast) contains a "long double" value
(not exactly representable in a "double"). This is prohibited by C99
(5.1.2.3#12, 6.3.1.5#2 and 6.3.1.8#2[52]). This problem seems to be fixed by
Joseph Myers' patch mentioned in comment #123 (but I haven't tried).
2. Computations on "double" expressions are carried out in extended precision.
This is allowed by C99 (except for casts and assignments), e.g. when
FLT_EVAL_METHOD=2. But if the implementation (i.e. here compiler + library +
...) claims to support Annex F, then this is prohibited. This point is rather
tricky because the compiler (GCC) and library (e.g. GNU libc) settings must be
consistent, so their developers need to talk with each other. FYI, I reported
the following bug concerning glibc:
http://sourceware.org/bugzilla/show_bug.cgi?id=6981
because it sets __STDC_IEC_559__ to 1 unconditionally.
> 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.
That's why in Joseph's patch, it's just an option (disabled by default, but
enabled by -std=c99 because one should assume that if a user wants C99, then he
really wants it, and if he is able to add an option, then he is also able to
add another one if he wants to disable this fix in case he knows it is useless
for his application -- this is also true for -ffast-math).
GCC already supports SSE, but this patch is for processors that don't.
Also the performance hit depends very much on the application. Performance hit
is reduced in applications that do not use intensive FP or mostly interactive
applications.
> 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
FYI, this is bug 34678. And I submitted bug 37845 concerning the FP_CONTRACT
pragma.
> * It is possible to force the x87 to use reduced precision for the mantissa
> (with inline asm or even now with gcc options).
Unfortunately, this means that "long double" wouldn't behave as expected, and
the behavior is not controllable enough (e.g. due to libraries, plugins...).
Such a change should have been system-wide. Now, this is needed in software
where double rounding is prohibited (e.g. XSLT processor).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
Reply to: