https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121143
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |rguenth at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In the cunroll pass dump which emits this warning I see
<bb 62> [local count: 954865874]:
# __n_22 = PHI <0(16)>
# ivtmp_170 = PHI <9(16)>
__n_55 = __n_22 + 1;
ivtmp_218 = ivtmp_170 - 1;
__n_177 = __n_55 + 1;
ivtmp_207 = ivtmp_218 + 18446744073709551615;
__n_247 = __n_177 + 1;
ivtmp_249 = ivtmp_207 + 18446744073709551615;
__n_256 = __n_247 + 1;
ivtmp_259 = ivtmp_249 + 18446744073709551615;
__n_342 = __n_256 + 1;
ivtmp_53 = ivtmp_259 + 18446744073709551615;
__n_47 = __n_342 + 1;
ivtmp_29 = ivtmp_53 + 18446744073709551615;
__n_351 = __n_47 + 1;
ivtmp_369 = ivtmp_29 + 18446744073709551615;
__n_359 = __n_351 + 1;
ivtmp_166 = ivtmp_369 + 18446744073709551615;
__n_206 = __n_359 + 1;
ivtmp_374 = ivtmp_166 + 18446744073709551615;
__first ={v} {CLOBBER(eos)};
if (__n_206 > 5)
goto <bb 22>; [0.04%]
else
goto <bb 38>; [99.96%]
<bb 22> [local count: 429152]:
std::__throw_bad_alloc ();
...
<bb 38> [local count: 954436725]:
<bb 23> [local count: 8677126674]:
# __ofirst_21 = PHI <_229(42), &v9.D.129568._M_elems(38)>
# __n_257 = PHI <__n_231(42), __n_206(38)>
# __ifirst$D135460$ptr_228 = PHI <_240(42), &a(38)>
# ivtmp_350 = PHI <ivtmp_254(42), 10(38)>
ivtmp_254 = ivtmp_350 - 1;
_227 = *__ifirst$D135460$ptr_228;
MEM[(_OutType *)__ofirst_21] = _227;
_229 = __ofirst_21 + 4;
_240 = __ifirst$D135460$ptr_228 + 4;
__n_231 = __n_257 + -1;
if (__n_231 != 0)
goto <bb 42>; [89.00%]
else
goto <bb 26>; [11.00%]
<bb 42> [local count: 7722642745]:
goto <bb 23>; [100.00%]
So, I believe __n_206 is constant 9 (just not propagated yet) and in that case
it should have called std::__throw_bad_alloc (); which I think is noreturn and
not actually done the loop afterwards.
The warning is on the __n_231 = __n_257 + -1; statement though, I don't see how
that one could invoke UB if __n_206 is not close to LLONG_MIN.
