On 9/12/25 3:20 PM, Vladimir Makarov wrote:
On 9/12/25 1:01 PM, Jeff Law wrote:
Shreya's work to add the addptr pattern on the RISC-V port exposed a
latent bug in LRA.
We lazily allocate/reallocate the ira_reg_equiv structure and when we
do (re)allocation we'll over-allocate and zero-fill so that we don't
have to actually allocate and relocate the data so often.
In the case exposed by Shreya's work we had N requested entries at the
last rellocation step. We actually allocate N+M entries. During LRA
we allocate enough new pseudos and thus have N+M+1 pseudos.
In get_equiv we read ira_reg_equiv[regno] without bounds checking so
we read past the allocated part of the array and get back junk which
we use and depending on the precise contents we fault in various fun
and interesting ways.
We could either arrange to re-allocate ira_reg_equiv again on some
path through LRA (possibly in get_equiv itself). We could also just
insert the bounds check in get_equiv like is done elsewhere in LRA.
Vlad indicated no strong preference in an email last week.
So this just adds the bounds check in a manner similar to what's done
elsewhere in LRA. Bootstrapped and regression tested on x86_64 as
well as RISC-V with Shreya's work enabled and regtested across the
various embedded targets.
OK for the trunk?
Yes. Thank you.
THanks. One more note for the record. No new test. With Shreya's
addptr patch this failure is exposed by the native testsuite on RISC-V.
I don't remember which test, but it was definitely an existing test that
failed for both the BPI and Pioneer.
Jeff
