https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61569
Bug ID: 61569
Summary: faggressive-loop-optimizations overoptimize loop
checks with unpredicted result
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: n-gcc at nn dot kiev.ua
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.
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.
