diff options
| author | Jeff Law <jlaw@ventanamicro.com> | 2025-11-13 08:51:40 -0700 |
|---|---|---|
| committer | Jeff Law <jlaw@ventanamicro.com> | 2025-11-13 08:53:43 -0700 |
| commit | 2ea9d663650fdcd7f8350e743047e72fe25d0a99 (patch) | |
| tree | 3a7125f92fa0c91506f4b665d342d90d36e27266 /libjava/classpath/gnu/java/beans/decoder/ArrayHandler.java | |
| parent | 14af70d6573102798316915f9b4a65b39e2c9ccb (diff) | |
[RISC-V][PR rtl-optimization/122627] Yet another fix in IRA equivalence array handling
Yup, yet another out of bounds access into the equivalence array.
In this case we had an out of bounds write, which corrupted the heap leading to
the fault.
Given this is the 3rd such issue in this space in recent history and the second
in this loop within LRA within a week or so, I looked for a solution that would
cover the whole loop rather than another spot fix.
The good news is this loop runs after elimination, so we can just expand the
equivalence array after elimination and all the right things should happen.
This also allows removal of the spot fix I did last week (which I did
backtest). I didn't have a testcase for the bug in this space I fixed a couple
months ago (and the artifacts from that build are certainly gone from my tester
by now).
Bootstrapped and regression tested on x86. Also verified the RISC-V failures
in this bz and bz122321 are fixed.
Given this is a refinement & simplification of a prior fix, I'm going to take
some slight leeway to push the fix forward now.
PR rtl-optimization/122627
gcc/
* lra-constraints.cc (update_equiv): Remove patch from last week
related to pr122321.
(lra_constraints): Expand the equivalence array after eliminations
are complete.
gcc/testsuite/
* gcc.target/riscv/rvv/autovec/pr122627.c: New test.
Diffstat (limited to 'libjava/classpath/gnu/java/beans/decoder/ArrayHandler.java')
0 files changed, 0 insertions, 0 deletions
