Bug 4251 - Bug in optimization of floating-point code
Summary: Bug in optimization of floating-point code
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2001-09-06 10:36 UTC by Bart Van Assche
Modified: 2003-07-01 18:45 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
NormalizeFloat.cpp (584 bytes, text/x-c++ )
2003-05-21 15:17 UTC, Bart Van Assche
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bart Van Assche 2001-09-06 10:36:00 UTC
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 Bart Van Assche 2001-09-06 10:36:00 UTC
Fix:
Either turn optimization off or put one of the calls to
Normalize() in a separate statement.
Comment 2 Alexandre Oliva 2001-09-28 20:20:13 UTC
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 Alexandre Oliva 2001-09-30 11:56:00 UTC
State-Changed-From-To: feedback->closed
State-Changed-Why: Reported confirmed that the difference was caused by excess precision.
Comment 4 Andrew Pinski 2003-07-01 18:44:59 UTC
Reopening bug to mark bug as a dup of bug 323 so ...
Comment 5 Andrew Pinski 2003-07-01 18:45:23 UTC
that the number of dup of that bug goes up.

*** This bug has been marked as a duplicate of 323 ***