Bug List: (This bug is not in your last search results)   Show last search results      Search page      Enter new bug
Bug#: 4251
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: Bart Van Assche <bart.vanassche@gmail.com>
Add CC:
CC:
Remove selected CCs
Build:
URL:
Summary:
Keywords:
Known to work:
Known to fail:

Attachment Description Type Created Size Actions
NormalizeFloat.cpp NormalizeFloat.cpp text/x-c++ 2003-05-21 15:17 584 bytes Edit
Create a New Attachment (proposed patch, testcase, etc.) View All

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

Additional Comments:






View Bug Activity   |   Format For Printing   |   Clone This Bug

Description:   Last confirmed: Opened: 2001-09-06 10:36 
When compiling the attached program with -O0, the program
exits with exit code 0 (echo $?) -- this is OK. When
compiling the attached program with -O2 however, then it
exits with exit code 1 -- this is wrong. I'm not sure
whether this really is a bug in the optimizer or the result
of rounding effects, but it is really something strange.
BTW, when replacing "<" by ">", the problem disappears.
It also looks like the problem only occurs when "step" has
a lot of bits behind the binary point (e.g. 0.1, 0.2 or
0.3, but not 0.5 or 0.25).

Release:
both 2.95.3 and 3.0

Environment:
RedHat Linux 6.1 with 2.4.7 kernel

How-To-Repeat:
g++ -O0 -Wall NormalizeFloat.cpp && (./a.out;echo $?)
g++ -O2 -Wall NormalizeFloat.cpp && (./a.out;echo $?)
will give you the output 0 and 1 on separate lines.

------- Comment #1 From Bart Van Assche 2001-09-06 10:36 ------- 
Fix:
Either turn optimization off or put one of the calls to
Normalize() in a separate statement.

------- Comment #2 From Alexandre Oliva 2001-09-28 20:20 ------- 
State-Changed-From-To: open->feedback
State-Changed-Why: See whether -ffloat-store ``fixes'' the problem.  If it does, you're being bitten by the excess precision in x86's FP registers.

------- Comment #3 From Alexandre Oliva 2001-09-30 11:56 ------- 
State-Changed-From-To: feedback->closed
State-Changed-Why: Reported confirmed that the difference was caused by excess precision.

------- Comment #4 From Andrew Pinski 2003-07-01 18:44 ------- 
Reopening bug to mark bug as a dup of bug 323 so ...

------- Comment #5 From Andrew Pinski 2003-07-01 18:45 ------- 
that the number of dup of that bug goes up.

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