[Bug target/64115] [4.9/5 Regression] ICE: : in rs6000_delegitimize_address, at config/rs6000/rs6000.c:7051
uweigand at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Dec 1 16:26:00 GMT 2014
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64115
Ulrich Weigand <uweigand at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dje.gcc at gmail dot com
--- Comment #3 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
The ICE is triggered by checking code in rs6000_delegitimize_address:
if (GET_CODE (y) == UNSPEC
&& XINT (y, 1) == UNSPEC_TOCREL)
{
#ifdef ENABLE_CHECKING
if (REG_P (XVECEXP (y, 0, 1))
&& REGNO (XVECEXP (y, 0, 1)) == TOC_REGISTER)
{
/* All good. */
}
else if (GET_CODE (XVECEXP (y, 0, 1)) == DEBUG_EXPR)
{
/* Weirdness alert. df_note_compute can replace r2 with a
debug_expr when this unspec is in a debug_insn.
Seen in gcc.dg/pr51957-1.c */
}
else
{
debug_rtx (orig_x);
abort ();
}
#endif
which attempts to ensure that the second argument of UNSPEC_TOCREL is the TOC
register. However, this check seems fragile; in debug code, we can get RTX
simplifications that replace the TOC register by some equivalent expression.
The code already recognizes one such case; this bug shows another case, where
the TOC register is replaced by a MEM RTX for the TOC save slot holding the TOC
value. [ This case is probably made more likely by the change in my ELFv2 ABI
preparation patch, which has the effect of making TOC moves into the save slot
more explicit at the RTL level, allowing var-tracking code to detect that
equivalence. ]
One could try to make this check in rs6000_delegitimize_address more generic by
allowing some (or all) MEM RTXes. However, I'm wonding what exactly that check
is supposed to achieve in the first place; for the purposes of this routine,
the second argument of UNSPEC_TOCREL is really irrelevant.
David, would you be OK with simply removing the check (everything enclosed with
ENABLE_CHECKING in the above code)?
More information about the Gcc-bugs
mailing list