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?
