Bug 11394 - optimization leads to broken double comparison
Summary: optimization leads to broken double comparison
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.2.2
: P2 normal
Target Milestone: 3.4.0
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2003-07-01 18:29 UTC by Hans Meine
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:

the original program (213 bytes, text/plain)
2003-07-01 18:31 UTC, Hans Meine
preprocessor output (70.74 KB, text/plain)
2003-07-01 18:32 UTC, Hans Meine

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Meine 2003-07-01 18:29:48 UTC
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" : ""); 
  g++ -Wall -O1 double_comparison.cxx -o double_comparison && 
  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.
Comment 1 Hans Meine 2003-07-01 18:31:35 UTC
Created attachment 4316 [details]
the original program

as given in the text, for your convenience
Comment 2 Hans Meine 2003-07-01 18:32:29 UTC
Created attachment 4317 [details]
preprocessor output

as requested on http://gcc.gnu.org/bugs.html
Comment 3 Andrew Pinski 2003-07-01 18:36:16 UTC
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 ***