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.
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.
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.
(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.
Dominique, did you mean to take this out of WAITING state? I'm assuming you didn't
(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.
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 ***