https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
--- Comment #7 from Matthew Fortune <matthew.fortune at imgtec dot com> --- (In reply to Eric Botcazou from comment #6) > > The issue may stem from the C front end where the dumps start off as below. > > Note that the '-1' in kappa-1 has ended up being represented as 1073741823 > > (0x3fffffff) presumably owing to the fact it will be multiplied by 4 > > eventually and hence be 'safe'. > > All pointer calculations are done in sizetype and it is unsigned. This kind > of issues generally come from the RTL level, maybe expansion here. The expansion looks like an acceptable transformation to me i.e. it is not introducing the overflow for the offending pointer just maintaining what is already in the tree. I dug back to reassoc2 based on Andrew's comment which gets the following as input: _48 = (sizetype) kappa_6(D); _49 = _48 * 8; _50 = s_37(D) + _49; ivtmp.19_47 = (unsigned int) _50 and then in the loop: _54 = (sizetype) s_37(D); _55 = ivtmp.19_3 - _54; _56 = _55 + 4294967280; # RANGE [0, 4294967295] NONZERO 4294967288 _19 = _56; # PT = nonlocal escaped _20 = _17 + _19; # VUSE <.MEM_4> _21 = *_20 This includes a pointer subtraction of 's' (somewhat pointless but valid I believe). reassoc2 changes it to this: _48 = (sizetype) kappa_6(D); _49 = _48 * 8; _50 = s_37(D) + _49; ivtmp.19_47 = (unsigned int) _50; and in the loop: _54 = (sizetype) s_37(D); _38 = -_54; _25 = 4294967280 - _54; _56 = _25 + ivtmp.19_3; # RANGE [0, 4294967295] NONZERO 4294967288 _19 = _56; # PT = nonlocal escaped _20 = _17 + _19; # VUSE <.MEM_4> _21 = *_20; And _56 is where we get the overflow. I'm still not sure if there is really a bug. Should reassoc not be doing this for 'sizetype'? Should ivopts not have created the mess in the first place? Would changing either of these actually introduce an assurance that this situation won't occur from other optimisations?
