| Summary: | optimization leads to broken double comparison | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Hans Meine <gccbug> |
| Component: | rtl-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | gcc-bugs |
| Priority: | P2 | ||
| Version: | 3.2.2 | ||
| Target Milestone: | 3.4.0 | ||
| Host: | i686-pc-linux-gnu | Target: | i686-pc-linux-gnu |
| Build: | i686-pc-linux-gnu | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
| Attachments: |
the original program
preprocessor output |
||
Created attachment 4316 [details]
the original program
as given in the text, for your convenience
Created attachment 4317 [details] preprocessor output as requested on http://gcc.gnu.org/bugs.html Read bug 323. This bug is invalid as it is the excessive precession problem with x86 using 80bit versus 64bit. From that bug: 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. *** This bug has been marked as a duplicate of 323 *** |
The following test program tests inequality of two doubles, then equality. The bug is that both will hold if - compiled with optimization (-O1 is enough) - first, an int was shifted into the ostream ---------------------------------------------- #include <iostream> #include <cmath> int main() { double dist1 = std::sqrt((2.0 - 6)*(2.0 - 6) + (2.0 - 1)*(2.0 - 1)); double dist2 = std::sqrt((5.0 - 6)*(5.0 - 6) + (5.0 - 1)*(5.0 - 1)); if(dist1 != dist2) { std::cerr << 1 // outputting any int here makes the bug show up << ((dist1 == dist2) ? "compiler broken\n" : ""); } } ---------------------------------------------- Executing g++ -Wall -O1 double_comparison.cxx -o double_comparison && ./double_comparison gives: 1compiler broken The bug was verified with 3.2.3 and 3.2, too. On 2.95.3, it does not show up. We tried to strip the program down as far as we could, hopefully you can shed light on this.