[Bug rtl-optimization/323] optimized code gives strange floating point results
------- Comment #112 from pepalogik at seznam dot cz 2008-06-21 22:38 -------
(In reply to comment #111)
> Concerning the standards: The x87 FPU does obey the IEEE754-1985 standard,
> which *allows* extended precision, and double precision is *available*.
It's true that double *precision* is available on x87. But not the *IEEE-754
"double precision" type*. Beside the precision of mantissa, this includes also
the range of exponent. On the x87, it is possible to set the precision of
mantissa but not the range of exponent. That's why I believe it doesn't obey
the IEEE. (I haven't ever seen the IEEE-754 standard but I base on the work of
> 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).
Do you mean that on Windows, long double has (by default) no more precision
than double? I don't think so (it's confirmed by my experience). According to
the paper of David Monniaux, only FreeBSD 4 sets double precision by default
(but I know almost nothing about BSD).
> > (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.
Yes, of course. I don't say this can be used everywhere.
> > (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).
OK but David Monniaux mentions portability issues just in the case of long
double, so the differences are probably more frequent in this case (maybe even
within the x86 architecture).
> Yes, but note that this is not the only problem with compilers. See e.g.
Thanks for info.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.