https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78176
mpf at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2017-01-16 CC| |mpf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |dgilmore at mips dot com Ever confirmed|0 |1 --- Comment #13 from mpf at gcc dot gnu.org --- (In reply to Maciej W. Rozycki from comment #11) > TBH this does look like trying to rely on UB to me, as per section > 6.5.6 "Additive operators" clause 8 of the C language standard, which > states (among others): > > "If both the pointer operand and the result point to elements of the > same array object, or one past the last element of the array object, > the evaluation shall not produce an overflow; otherwise, the behavior > is undefined." > > Here under the triggering conditions the pointer the integer is added > to with LDXC1 does not point to an element of the array operated on (or > to one past the last), so the hardware operation matches the standard's > semantics WRT overflow and I don't think we ought to be pushing it. Aren't language rules mostly irrelevant at this stage though? We don't really have the concept of a pointer after generating RTL we just happen to have some values in a mode that is the same as Pmode. mips.h comment for Pmode: /* Specify the machine mode that pointers have. After generation of rtl, the compiler makes no further distinction between pointers and any other objects of this machine mode. */ > So it looks like a middle end bug to me and the backend is fine in > faithfully assuming its RTL pattern won't be passed operands leading to > UB. I can't see any feature/option/setting that gives this guarantee. Why do you think the backend can make this assumption?