https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69252
Martin Sebor <msebor at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target|powerpc64-unknown-linux-gnu |powerpc64*-unknown-linux-gn | |u Status|UNCONFIRMED |NEW Last reconfirmed| |2016-01-13 CC| |msebor at gcc dot gnu.org Host|x86_64-pc-linux-gnu | Ever confirmed|0 |1 --- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> --- Confirmed with today's top of trunk (6.0.0 20160113) also on powerpc764le with -O1 and -Os. Using a slightly simplified test case int a[N] = { 0, 2, 4, 8 }; __attribute__ ((noinline, noclone)) int main1 (void) { int s = 0; int i; for (i = 0; i != sizeof a / sizeof *a; i++) s += i + a[i]; return s; } and looking at the tree dumps, the first one that looks suspicious (with -O1) is: $ cat t.c.152t.ivopts ;; Function main1 (main1, funcdef_no=0, decl_uid=2350, cgraph_uid=0, symbol_order=1) __attribute__((noclone, noinline)) main1 () { unsigned long ivtmp.10; int i; int s; int _4; int _5; int * _14; void * _15; <bb 2>: _14 = &a + 18446744073709551612; ivtmp.10_13 = (unsigned long) _14; <bb 3>: # s_10 = PHI <s_6(4), 0(2)> # i_12 = PHI <i_7(4), 0(2)> # ivtmp.10_9 = PHI <ivtmp.10_8(4), ivtmp.10_13(2)> ivtmp.10_8 = ivtmp.10_9 + 4; _15 = (void *) ivtmp.10_8; _4 = MEM[base: _15, offset: 0B]; _5 = _4 + i_12; s_6 = _5 + s_10; i_7 = i_12 + 1; if (i_7 != 4) goto <bb 4>; else goto <bb 5>; <bb 4>: goto <bb 3>; <bb 5>: # s_11 = PHI <s_6(3)> return s_11; }