Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 11394
Product:  
Component:  
Status: RESOLVED
Resolution: DUPLICATE of bug 323
Assigned To: Not yet assigned to anyone <unassigned@gcc.gnu.org>
Host:
Reported against  
Priority:  
Severity:  
Target Milestone:  
 
 
Target:
Reporter: Hans Meine <gccbug@chiefrocker.net>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
double_comparison.cxx the original program text/plain 2003-07-01 18:31 213 bytes Edit
double_comparison.ii.bz2 preprocessor output text/plain 2003-07-01 18:32 70.74 KB Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 11394 depends on: Show dependency tree
Show dependency graph
Bug 11394 blocks:

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug

Description:   Last confirmed: Opened: 2003-07-01 18:29 
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.

------- Comment #1 From Hans Meine 2003-07-01 18:31 ------- 
Created an attachment (id=4316) [edit]
the original program

as given in the text, for your convenience

------- Comment #2 From Hans Meine 2003-07-01 18:32 ------- 
Created an attachment (id=4317) [edit]
preprocessor output

as requested on http://gcc.gnu.org/bugs.html

------- Comment #3 From Andrew Pinski 2003-07-01 18:36 ------- 
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 ***
Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug