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.