https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116244
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #2 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Looks like another path using subreg_regno_offset without verifying it's
actually a subreg expression that can be simplified. Like the prior m68k bug
we have
(subreg:DI (reg:SI d0) 0)
So a paradoxical reference to register 0. This time it's reload calling
alter_subreg. alter_subreg calls subreg_regno which looks like:
/* Return the final regno that a subreg expression refers to. */
unsigned int
subreg_regno (const_rtx x)
{
unsigned int ret;
rtx subreg = SUBREG_REG (x);
int regno = REGNO (subreg);
ret = regno + subreg_regno_offset (regno,
GET_MODE (subreg),
SUBREG_BYTE (x),
GET_MODE (x));
return ret;
}
Which is going to return -1 for the case above. So we install -1 as the
register number and all hell breaks loose after that.
I think the sensible thing to do with a subreg we're not going to simplify is
to just return the original register #. But I need to put that through the
testsuite on a few targets to ensure no fallout. subreg_regno isn't a heavily
used API thankfully.
