[Bug tree-optimization/61569] faggressive-loop-optimizations overoptimize loop checks with unpredicted result

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61569

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Valentin Nechayev from comment #0)
> The following program performs 112 iterations (and stop on x==1) instead of
> expected 10 ones.
> 
> #include <stdio.h>
> 
> int main()
> {
>     int i, x = 27;
>     for (i = 0; i < 10; ++i)
>     {
>         printf("%11d : %11d : %d\n", i, i*1000000000, x);
>         if (x==1) break;
>         x = x%2 ? x*3+1 : x/2;
>     }
>     return 0;
> }
> 
> With a small change, it, instead, limits itself to 3 iterations.
> 
> #include <stdio.h>
> 
> int main()
> {
>     int i, j, x = 27;
>     for (i = j = 0; i < 10; ++i, ++j)
>     {
>         printf("%11d : %11d : %d\n", i, j*1000000000, x);
>         if (x==1) break;
>         x = x%2 ? x*3+1 : x/2;
>     }
>     return 0;
> }
> 
> Conditions to represent the issue are:
> 1. gcc after 4.8.0 (my versions gcc48-4.8.4.s20140605 and
> gcc49-4.9.1.s20140611 from FreeBSD ports).
> 2. -O2 or higher, or -Os.
> 
> The issue goes after any of the following options added:
> * -fno-aggressive-loop-optimizations
> * -fno-strict-overflow
> * -fwrapv or -ftrapv (obviously)
> 
> Stage dump analysis shows that loop exit condition check (i<10 in that code
> examples, i<=9 internally after some change) is gone away at 056t.cunrolli.
> 
> Adding of -Wstrict-overflow of any level doesn't cause warning emission.
> 
> The similar issue was reported in #58143 comment 9, and #53265 seems devoted
> to lack of warning, but I'm not sure cases are equal.
> 
> Disclaimer: I'm aware of standard's statement "signed integer overflow is
> UB" but I'm confident that a respected common-goal compiler should
> thoroughly limit this UB to result value of the operator itself and avoid
> expanding it to any other program action.

Unfortunately that's not possible.

> Thanks to: livejournal.com user _winnie for issue finding; user kodt_rsdn
> (Nikolay Merkin) for the clear example designing; Serge Ryabchun for
> diagnosing -faggressive-loop-optimizations influence.