[Bug c++/47600] New: gcc optimizer seems to avoid necessary floating-point addition

[Bug c++/47600] New: gcc optimizer seems to avoid necessary floating-point addition

[acfbuerger at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47600

           Summary: gcc optimizer seems to avoid necessary floating-point
                    addition
           Product: gcc
           Version: 4.5.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: acfbuerger@googlemail.com


Created attachment 23237
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23237
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.

[Bug c++/47600] gcc optimizer seems to avoid necessary floating-point addition

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47600

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011.02.03 16:49:41
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 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.

[Bug c++/47600] gcc optimizer seems to avoid necessary floating-point addition

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47600

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
     Ever Confirmed|1                           |0

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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.

[Bug c++/47600] gcc optimizer seems to avoid necessary floating-point addition

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47600

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 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.

[Bug c++/47600] gcc optimizer seems to avoid necessary floating-point addition

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47600

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|2011-02-03 16:49:41         |2011.02.03 17:56:32
     Ever Confirmed|0                           |1

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-02-03 17:56:32 UTC ---
Dominique, did you mean to take this out of WAITING state?
I'm assuming you didn't

[Bug c++/47600] gcc optimizer seems to avoid necessary floating-point addition

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47600

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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.

[Bug c++/47600] gcc optimizer seems to avoid necessary floating-point addition

[acfbuerger at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47600

Alexander Bürger <acfbuerger at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #6 from Alexander Bürger <acfbuerger at googlemail dot com> 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 ***