[Bug tree-optimization/113774] wrong code with _BitInt() arithmetics at -O2

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
This must go wrong during alias disambiguation, somehow figuring we can ignore
the backedge?!  The ref we hoist is

  _68 = VIEW_CONVERT_EXPR<unsigned long[5]>(b)[_146];

where _146 is _49 + 1, but _49 is an IV:

  _134 = _105 & 1;
  MEM <unsigned long> [(unsigned _BitInt(257) *)&b + 32B] = _134;

  <bb 5> [local count: 1073741824]:
  # _49 = PHI <0(4), _50(28)>

it's also odd that we seem to arrive at b + 32B.

Value numbering stmt = _146 = PHI <_145(8), _140(31)>
Setting value number of _146 to _140 (changed)
Making available beyond BB10 _146 for value _140
...
Value numbering stmt = .MEM_150 = PHI <.MEM_149(8), .MEM_139(31)>
Setting value number of .MEM_150 to .MEM_150 (changed)
Value numbering stmt = _68 = VIEW_CONVERT_EXPR<unsigned long[5]>(b)[_146];
Setting value number of _68 to _134 (changed)

huh.

Hmm.  But we have

  # RANGE [irange] sizetype [4, 4][6, +INF] MASK 0xfffffffffffffffe VALUE 0x1
  _140 = _49 + 1;

  # RANGE [irange] sizetype [1, 2][4, 4][6, +INF] MASK 0xfffffffffffffffe VALUE
0x1 
  # _146 = PHI <_145(8), _140(6)>

we should look at the range of _146

Hmm, I _think_ I know what happens.  We have

<bb 5> [local count: 1073741824]:
# _49 = PHI <0(4), _50(28)>
# _55 = PHI <0(4), _56(28)>
_51 = VIEW_CONVERT_EXPR<unsigned long[5]>(b)[_49];
if (_49 <= 2)
  goto <bb 7>; [80.00%]
else
  goto <bb 6>; [20.00%]

<bb 6> [local count: 214748360]:
_135 = .USUBC (0, _51, _55);
_136 = IMAGPART_EXPR <_135>;
_137 = REALPART_EXPR <_135>;
_138 = _51 | _137;
bitint.6[_49] = _138;
_140 = _49 + 1;
_141 = VIEW_CONVERT_EXPR<unsigned long[5]>(b)[_140];

and this is the "same" valueized ref (what gets recorded in the hashtable),
but here we can see that _140 >= 4 which makes it known 4 based on the
array extent.  This matches it up with the store of _134:

Value numbering stmt = _141 = VIEW_CONVERT_EXPR<unsigned long[5]>(b)[_140];
Setting value number of _141 to _134 (changed)
_134 is available for _134

we record the expression with the VUSE of the definition.  Later when we
look up the same expression from the later block (where _140 isn't known
to be 4) we find the very same expression when looking with the VUSE of
the definition and thus we take the expression already in the hashtable
which has been assigned the value _134 and then boom.

Sth like the following is miscompiled at -O2 by FRE.

int a[3];
int __attribute__((noipa))
foo(int i, int x)
{
  int tem = 0;
  a[2] = x;
  if (i < 1)
    ++i;
  else
    {
      ++i;
      tem = a[i];
    }
  tem += a[i];
  return tem;
}

int main() { if (foo (0, 7) != 0) __builtin_abort(); }