> Am 12.09.2025 um 19:03 schrieb Jeff Law <[email protected]>:
>
> 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.
Richard
>
> Jeff
> <P>
