[Bug middle-end/106892] [11/12/13 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.