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.
