[Bug target/78176] [MIPS] miscompiles ldxc1 with large pointers on 32-bits

[matthew.fortune at imgtec dot com]

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?