[Bug bootstrap/68404] [6 Regression] PGO/LTO bootstrap failure on ppc64le

[rsandifo at gcc dot gnu.org]

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.