Bug 47600 - gcc optimizer seems to avoid necessary floating-point addition
Summary: gcc optimizer seems to avoid necessary floating-point addition
Status: RESOLVED DUPLICATE of bug 323
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.5.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-03 16:36 UTC by Alexander Bürger
Modified: 2011-03-08 19:08 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-02-03 17:56:32


Attachments
assembly and g++ -v output (1.49 KB, application/octet-stream)
2011-02-03 16:36 UTC, Alexander Bürger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Bürger 2011-02-03 16:36:57 UTC
Created attachment 23237 [details]
assembly and g++ -v output

g++ versions tested: g++-4.5 (Ubuntu/Linaro 4.5.1-7ubuntu2)  4.5.1
                     g++-4.4 (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5

Problem: I have code like this:

double fakeManipulation(double d) { return d; }
...
dist = <about 100>
const double d = <very small number, 1e-16>;
const double ndist = dist+d; // does not work with optimizer
//const double ndist = fakeManipulation(dist+d); // works with optimizer
if( ndist <= dist )
    <avoid endless loop>

The comparison in the if statement is intended exactly like this: check if d is so small that adding it to dist does not make any difference because of the limited floating-point precision. I do not know a simpler way to do that which is equally fast and independent of the actual values of d and dist.

When compiling this code without optimization, the comparison is handled correctly and the endless loop is avoided.

When compiling with -O or -O2, the comparison is NOT handled correctly and the program runs into an endless loop. With -O and -O2 and the fakeManipulation call, it is also handled correctly.

My suspicion is that the optimizer replaces the comparison with (d<=0) which is not numerically correct. 

The full code is rather lengthy and I did not succeed to write a small demonstration program, so I attached parts of the generated assembler code.
Comment 1 Richard Biener 2011-02-03 16:49:41 UTC
Are you on a 32bit i?86 machine?  Try -std=c99 or -mfpmath=sse, you probably
run into bug 323.

Also please provide a testcase that we can compile to reproduce the issue.
Comment 2 Dominique d'Humieres 2011-02-03 16:55:59 UTC
Does C* obey parentheses? If yes, the solution is the same as in Fortran ndist =(dist+d). If no, I think there is an option to disable reassociation (-fno-tree-reassoc?) otherwise ndist-dist is d.
Comment 3 Richard Biener 2011-02-03 16:58:51 UTC
(In reply to comment #2)
> Does C* obey parentheses? If yes, the solution is the same as in Fortran ndist
> =(dist+d). If no, I think there is an option to disable reassociation
> (-fno-tree-reassoc?) otherwise ndist-dist is d.

We don't reassociate unless you enable it.  Thus it should work at -O2
and the assembly looks ok (but the constant is stripped).  This really
looks like 323.
Comment 4 Jonathan Wakely 2011-02-03 17:56:32 UTC
Dominique, did you mean to take this out of WAITING state?
I'm assuming you didn't
Comment 5 Dominique d'Humieres 2011-02-03 19:02:55 UTC
(In reply to comment #4)
> Dominique, did you mean to take this out of WAITING state?
> I'm assuming you didn't

I think the WAITING state followed comment #1.
Comment 6 Alexander Bürger 2011-03-08 19:08:38 UTC
It is a 32bit i?86 machine and my impression is that this is bug 323. The problem disappears when ndist is stored in a "volatile double".

I have not been able to produce a test case. As there seems to be a dependency on optimization, I am probably just unlucky. I must say that I do not understand why bug 323 should not be regarded as a bug.

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