On 9/13/25 4:16 AM, Richard Biener wrote:
Am 12.09.2025 um 19:03 schrieb Jeff Law <j...@ventanamicro.com>:
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?
If the issue is latent on branches I suggest to backport as well given the
‚undefined‘ failure mode.
Yea. I'd hate someone else to have to chase it down again. I'll take
care of it.
jeff
