https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #13 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to Bill Schmidt from comment #10)
> Looking at scan_rtx_address () in regrename.c, it indeed looks like a PLUS
> nested inside a PLUS isn't handled. I'm not sure if this is a deficiency in
> regrename.c, or whether the definition of fusion_gpr_load_di is just playing
> with fire here. Richard S., do you have an opinion?
Like you say, I don't think nested (plus ... (const_int))s are valid.
It still sounds like a deficiency if they trigger wrong code though --
an ICE would be OK.
I'm probably misreading the code, but I don't see how scan_rtx_address
would get this wrong. The first (plus ... (const_int)) ought to go
through:
else if (code1 == CONST_INT || code1 == CONST
|| code1 == SYMBOL_REF || code1 == LABEL_REF)
{
locB = &XEXP (x, 0);
index_code = GET_CODE (XEXP (x, 1));
}
and then we'd recurse with locB treated as a base address. *locB
is the inner plus and ought to come through the same code again,
meaning that we recurse a second time with locB pointing to r9.
So there might still be a regrename.c bug here.
