[Bug rtl-optimization/323] optimized code gives strange floating point results
------- Comment #111 from vincent at vinc17 dot org 2008-06-20 16:09 -------
(In reply to comment #109)
> WHERE'S THE BUG
> This is really not a GCC bug. The bug is actually in the x87 FPU because it
> doesn't obey the IEEE standard.
Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard,
which *allows* extended precision, and double precision is *available*. In
fact, one could say that GCC even obeys the IEEE standard (which doesn't define
bindings: the definition of "destination" page 4 of the IEEE754-1985 standard
is rather vague and lets the language to define it exactly), but it doesn't
obey the ISO C99 standard on some point.
Concerning the x87 FPU: One can say however that the x87 is a badly designed
because it is not possible to statically specify the precision. Nevertheless
the OS/language implementations should take care of this problem.
Note: the solution chosen by some OS'es (*BSD, MS-Windows...) is to configure
the processor to the IEEE double precision by default (thus "long double" is
also in double precision, but this is OK as far as the C language is concerned,
there's still a problem with "float", but in practice, nobody cares AFAIK).
> If you wish to compile for processors which don't have SSE, you have a few
> possibilities:
> (1) A very simple solution: Use long double everywhere.
This avoids the bug, but this is not possible for software that requires double
precision exactly, e.g. XML tools that use XPath. See other examples here:
http://www.vinc17.org/research/extended.en.html
Also this makes maintenance of software more difficult because long double can
be much slower on some platforms, which support this type in software to
provide more precision (e.g. PowerPC Linux and Mac OS X implement a
double-double arithmetic, Solaris and HPUX implement quadruple precision).
> (But be careful when transfering binary data in long double format between
> computers because this format is not standardized and so the concrete bit
> representations vary between different CPU architectures.)
Well, this is not specific to long double anyway: there exist 3 possible
endianess for the double format (x86, PowerPC, ARM).
> (2) A partial but simple solution: Do comparisons on volatile variables only.
Yes (but this is also a problem concerning the maintenance of portable
programs).
> (4) A complex solution: [...]
Yes, this is the workaround I use in practice.
> RECOMMENDATIONS
> I think this problem is really serious and general. Therefore, programmers
> should be warned soon enough.
Yes, but note that this is not the only problem with compilers. See e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36578
for a bug related to casts to long double on x86_64 and ia64. This one is now
tested by: http://www.vinc17.org/software/tst-ieee754.c (which has also tested
bug 323 for a long time).
--
vincent at vinc17 dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vincent at vinc17 dot org
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: