[Bug target/9736] same fp comparison can lead to different results

[richard at wetafx dot co dot nz]

------- Additional Comments From richard at wetafx dot co dot nz  2004-04-01 22:42 -------
(In reply to comment #13)
> This is a dup of bug 1098.
> 
> *** This bug has been marked as a duplicate of 1098 ***

Really, when users requests standard optimization (using one of the
-O1, -O2, -O3, -Os options), the compiler should not gratuitously
violate the standards of the languages being compiled.  Casual users
should be able to ask for optimization and still get the same
computational results.  For users who want to tune for additional
performance, they could then choose additional specific options that
trade off standards compliance, reliability, dependability, and
predictability for speed. (Such trade-offs should be documented,
of course).

Optimization that violates standards compliance can lead to generating
code that does not terminate for numerical algorithms that expect
reasonable standards compliance.  Even when iteration limits are
put into place, such optimized code can still run much slower than
unoptimized code.  What's the point then?

Why has this bug been marked as a duplicate of 1098, when bug 1098
did not mention optimization?  Is it just being lumped into a
"oh, that's an issue with supporting x387 floating point; surely
everyone's going to have SSE2 instructions soon so we'll never
have to fix it" pile?

And how can this bug be marked as a resolved duplicate of another
bug when that other bug is not resolved?

Fortunately for me, I no longer have to support any x387 machines.
That wasn't the case a year ago.

-- 


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