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.
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 ***