On Thu, 10 Feb 2011 11:39:57 EST, Leon Kaiser said:
> "Yay open source"?
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
>From comment #2 on that bug:
State-Changed-Why: See any faq on numerical analysis that mentions the x86.
You are seeing the results of excess precision in the FPU.
Either change the rounding precision in the FPCR, or work
around the problem with -ffloat-store.
Let's look at the problematic line in the sample code:
if (y != y2) printf("error\n");
This will cause the printf to trigger if the two numbers are bitwise identical
down to the last bit. If y and y2 were computed via different code paths, and
thus hit different patterns of rounding and truncation, they could easily be
different in the last bit or two (for example, 3.993428883437 and
3.993428883436). It's been well understood since literally the 1950s that if
you're trying to do any serious floating-point computation, such comparisons
should usually be written as 'if (abs(y - y2) < epsilon)' for whatever value of
epsilon you're willing to accept as a fuzz factor.
Although it's probably possible to "fix" gcc to do the right thing for the test
case in the bug report, it's in general *not* possible to "fix" this in the
general case. It just becomes a total mess of little special corner cases and
makes performance of both the optimizer and the generated code totally tank.
There's only a limited amount of things the compiler and optimizer can do to
save
a programmer from improper numeric analysis.
For further details, read comment 109 and/or the paper referenced in
comment 96. Many of the other comments are also relevant.
Attachment:
pgp7Qc6bd7u3T.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/