https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the reason is that we have
# RANGE [-2147483643, 2]
_137 = 4 - prephitmp_80;
f[_137] = _139;
which makes us conclude the f[_137] access is constrained to f[0..2]. When
we see
_75 = MEM[(int *)_20 + 16B];
we then disambiguate because iff _20 points into 'f' then with offset 16
it's beyond that constrained access. _But_!
# RANGE [18446744065119617028, 18446744073709551608]
_5 = _39 * -4U;
# PT = anything
_20 = &f + _5;
_20 is actually _before_ 'f' which we consider invalid.
Now here's what the frontend presents us with:
f[4 - d] = f[4 - d] ^ 3;
which we eventually gimplify to
_5 = 4 - d.1_4;
_6 = f[_5];
but then predictive commoning comes along:
Load motion chain 0x43bb3d0
inits MEM[(int *)_20 + 16B]
references:
f[_2] (id 0)
offset 0
distance 0
f[_2] (id 1, write)
offset 0
distance 0
Executing predictive commoning without unrolling
<bb 36> [local count: 35740571]:
+ _39 = (sizetype) prephitmp_80;
+ _5 = _39 * 18446744073709551612;
+ _20 = &f + _5;
+ _75 = MEM[(int *)_20 + 16B];
<bb 11> [local count: 289173710]:
# ivtmp_48 = PHI <ivtmp_68(22), 7(36)>
+ # f_I_lsm0.27_12 = PHI <f_I_lsm0.27_1(22), _75(36)>
_2 = 4 - prephitmp_80;
- _3 = f[_2];
+ _3 = f_I_lsm0.27_12;
introducing this kind of problem. We have a "opt-out" with using
TARGET_MEM_REF which is exempt from this rule because IVOPTs also likes to
break it.
