https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108388
Bug ID: 108388
Summary: LRA generates RTL that violates constraints
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pkoning at gcc dot gnu.org
Target Milestone: ---
Created attachment 54259
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54259&action=edit
Reproducer for this issue
In gcc for pdp11-aout, compiling with LRA enabled (-mlra) and optimization (-Os
or -O2) I get an ICE when building libgcc2. The issue appears to be that LRA
first assigns a hard register for the destination of an addhi3 RTL,
specifically R5. R5 is the frame register, but it can be eliminated. The
source is an address computed from the frame pointer, i.e., a (plus (r5) (const
int something)). The machine is a two-operand machine, so in patterns like
addhi3 the operand descriptor for operand 1 (first source) requires it to be
the same as operand 0 (destination).
So far so good. The assigned register indeed satisfies that constraint.
But apparently after that point LRA decides to eliminate the frame register, so
it simply replaces that frame-related reference in the source by a stack
pointer based reference, of the form (plus (sp) (const int something-else)).
At this point we have a constraint violation because operands 0 and 1 are now
different (r5 and sp respectively). Correct code would require copying sp into
some other register then doing the addhi3 with that register.
The code compiles correctly with old reload (the default, in the currently
committed pdp11 target).
