[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Jeffrey A. Law --- Should be resolved on the trunk. Thanks Vlad!
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #19 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:2341f675edadd6370147d2bc55ca7761a7ecfaa1 commit r15-7700-g2341f675edadd6370147d2bc55ca7761a7ecfaa1 Author: Vladimir N. Makarov Date: Tue Feb 25 15:01:15 2025 -0500 [PR115458][LRA]: Run split sub-pass more times In this PR case LRA needs to provide too many hard regs for insn reloads, where some reload pseudos require 8 aligned regs for themselves. As the last attempt, LRA tries to split live ranges of hard regs for insn reload pseudos. It is a very rare case. An inheritance pseudo involving a reload pseudo of the insn can be spilled in the assignment sub-pass run right after splitting and we need to run split sub-pass for the inheritance pseudo now. gcc/ChangeLog: PR target/115458 * lra-int.h (LRA_MAX_FAILED_SPLITS): Define and check its value. (lra_split_hard_reg_for): Change prototype. * lra.cc (lra): Try to split hard reg range several times after a failure. * lra-assigns.cc (lra_split_hard_reg_for): Add an arg, a flag of giving up. Report asm error and nullify the asm insn depending on the arg value. gcc/testsuite/ChangeLog: PR target/115458 * g++.target/riscv/pr115458.C: New.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #18 from Vladimir Makarov --- Created attachment 60549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60549&action=edit Reduced test case
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #17 from Vladimir Makarov --- The bug seems like wrong repeated interaction hard reg live range splitting and inheritance. I'll try to make a patch and hope to fix it on this week.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #16 from Jeffrey A. Law ---
This is looking more and more like an LRA bug to me.
After IRA we have this sequence:
(insn 30 28 31 2 (set (reg:QI 10 a0)
(reg:QI 151 [ D.129558 ])) "j.C":71:30 284 {*movqi_internal}
(nil))
(call_insn 31 30 73 2 (parallel [
(set (reg:RVVM8QI 104 v8)
(call (mem:SI (symbol_ref:DI
("_Z15InterleaveUpperI4SimdIcLl1EEu14__rvv_int8m8_tET0_T_S3_S3_") [flags 0x41]
) [0 InterleaveUpper S4 A32])
(const_int 0 [0])))
(use (unspec:SI [
(const_int 1 [0x1])
] UNSPEC_CALLEE_CC))
(clobber (reg:SI 1 ra))
]) "j.C":71:30 468 {call_value_internal}
(expr_list:REG_DEAD (reg:QI 10 a0)
(expr_list:REG_DEAD (reg:RVVM8QI 112 v16)
(expr_list:REG_CALL_DECL (symbol_ref:DI
("_Z15InterleaveUpperI4SimdIcLl1EEu14__rvv_int8m8_tET0_T_S3_S3_") [flags 0x41]
)
(nil
(expr_list:QI (use (reg:QI 10 a0))
(expr_list:RVVM8QI (use (reg:RVVM8QI 104 v8))
(expr_list:RVVM8QI (use (reg:RVVM8QI 112 v16))
(nil)
(insn 73 31 33 2 (parallel [
(set (reg:RVVM8QI 159 [ v8 ])
(reg:RVVM8QI 104 v8))
(use (reg:SI 67 vtype))
]) "j.C":71:30 2850 {*movrvvm8qi_reg_whole_vtype}
(nil))
(insn 33 73 37 2 (set (reg:RVVM1BI 145 [ _16 ])
(if_then_else:RVVM1BI (unspec:RVVM1BI [
(const_vector:RVVM1BI repeat [
(const_int 1 [0x1])
])
(const_int 0 [0])
(const_int 2 [0x2])
(const_int 0 [0])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(gt:RVVM1BI (reg:RVVM8QI 135 [ _4 ])
(const_vector:RVVM8QI repeat [
(const_int 0 [0])
]))
(unspec:RVVM1BI [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))) "j.C":51:34 12655 {*pred_cmprvvm8qi_narrow}
(expr_list:REG_DEAD (reg:DI 0 zero)
(nil)))
(insn 37 33 35 2 (set (reg:QI 10 a0)
(reg:QI 151 [ D.129558 ])) "j.C":72:17 discrim 1 284 {*movqi_internal}
(nil))
(insn 35 37 38 2 (set (reg:RVVM8QI 112 v16)
(if_then_else:RVVM8QI (unspec:RVVM1BI [
(reg:RVVM1BI 145 [ _16 ])
(const_int 0 [0])
(const_int 2 [0x2])
(const_int 0 [0]) repeated x2
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(minus:RVVM8QI (reg:RVVM8QI 135 [ _4 ])
(reg:RVVM8QI 159 [ v8 ]))
(reg:RVVM8QI 159 [ v8 ]))) "j.C":72:17 discrim 1 5590
{pred_subrvvm8qi}
(expr_list:REG_DEAD (reg:SI 67 vtype)
(expr_list:REG_DEAD (reg:SI 66 vl)
(nil
(call_insn 38 35 40 2 (parallel [
(call (mem:SI (symbol_ref:DI
("_Z14AssertVecEqualI4SimdIcLl1EEEvT_DTcl4ZerocvS2__EEES3_") [flags 0x41]
) [0 AssertVecEqual S4 A32])
(const_int 0 [0]))
(use (unspec:SI [
(const_int 1 [0x1])
] UNSPEC_CALLEE_CC))
(clobber (reg:SI 1 ra))
]) "j.C":72:17 discrim 1 467 {call_internal}
(expr_list:REG_DEAD (reg:QI 10 a0)
(expr_list:REG_DEAD (reg:RVVM8QI 112 v16)
(expr_list:REG_DEAD (reg:RVVM8QI 104 v8)
(expr_list:REG_CALL_DECL (symbol_ref:DI
("_Z14AssertVecEqualI4SimdIcLl1EEEvT_DTcl4ZerocvS2__EEES3_") [flags 0x41]
)
(nil)
(expr_list:QI (use (reg:QI 10 a0))
(expr_list:QI (use (reg:QI 10 a0))
(expr_list:RVVM8QI (use (reg:RVVM8QI 104 v8))
(expr_list:RVVM8QI (use (reg:RVVM8QI 112 v16))
(nil)
A few points to note. Insn 31 is obviously a call which sets v8..v15, as
expected. We do copy the result into a pseudo at insn 73. But note we keep
the v8..v15 live. That is potentially worrisome.
Insn 33 is pretty straightforward, though it is worth noting that with LMUL=8
the output is an earlyclobber.
Insn 35 is our problem. Note that it has a hard register ouput (v16..v23),
that's a result of it being used as an argument register for the call at insn
38. The call at insn 38 is also using the value in v8..v15 as the other
argument. If we assume that v8..v15 are live, v0 is the mask, that leaves just
v16..23 and v24..31 for the input operands. ie, we're going to have to tie an
input to an output to get a valid allocation. But neither of the arguments to
the MINUS are dead. Clearly we're going to need some reloading.
If we didn't have v8..15 already live, then we could potentially have had an
easy allocation. I explored that a bit by hacking up cse and using
compile-time flags to ensure the copy that was originally
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #15 from Jeffrey A. Law --- I was concerned about that hardreg usage as well. It's from argument setup. I did an experiment around that, essentially reporting that vector regs were always likely to be spilled. That prevents us from using the hard register in a complex insn and (as expected) the complex insn sets a pseudo which is then copied into the appropriate hard reg. It all looked quite sensible, but it didn't change the failure mode. Don't get me wrong, argument passing is part of the triggering prereqs, essentially the uses as argument registers crank up the register pressure at the key point. A single one of these grouped registers can be live at this point and LRA should be able to handle it (by tying one of the inputs to one of the outputs). If two register groups are live and unspillable, then there won't be any valid path for reloading. That's esentially the thread to pull on today. I'm not a fan of the whole LMUL concept. But it is what it is :(
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #14 from rguenther at suse dot de ---
On Fri, 7 Feb 2025, law at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
>
> --- Comment #13 from Jeffrey A. Law ---
> So just recording some thoughts as I initially look at this.
>
> This is the key insn (from the combine dump).
>
> (insn 35 34 37 2 (set (reg:RVVM8QI 112 v16)
> (if_then_else:RVVM8QI (unspec:RVVM1BI [
> (reg:RVVM1BI 145 [ _17 ])
> (const_int 0 [0])
> (const_int 2 [0x2])
> (const_int 0 [0]) repeated x2
> (reg:SI 66 vl)
> (reg:SI 67 vtype)
> ] UNSPEC_VPREDICATE)
> (minus:RVVM8QI (reg:RVVM8QI 135 [ _5 ])
> (reg:RVVM8QI 143 [ _13 ]))
> (reg:RVVM8QI 143 [ _13 ]))) "j.C":72:17 discrim 1 5590
> {pred_subrvvm8qi}
> (expr_list:REG_DEAD (reg:SI 66 vl)
> (expr_list:REG_DEAD (reg:SI 67 vtype)
> (nil
>
> The first thing that popped out to me was the hard register usage for the
> output. That's because the output is used as an argument. That led me to
> realize that v8 is also holding live data. v0, of course, will be needed for
> the mask. So to get a successful allocation with no reloading we'd have to
> have tie one of the inputs with the output.
Why did we end up with the hardreg in this complex insn in the first
place? We should avoid propagating those before RA and they should
only appear in hardreg<->pseudo moves or in special cases in insns
right from RTL expansion on.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #13 from Jeffrey A. Law ---
So just recording some thoughts as I initially look at this.
This is the key insn (from the combine dump).
(insn 35 34 37 2 (set (reg:RVVM8QI 112 v16)
(if_then_else:RVVM8QI (unspec:RVVM1BI [
(reg:RVVM1BI 145 [ _17 ])
(const_int 0 [0])
(const_int 2 [0x2])
(const_int 0 [0]) repeated x2
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(minus:RVVM8QI (reg:RVVM8QI 135 [ _5 ])
(reg:RVVM8QI 143 [ _13 ]))
(reg:RVVM8QI 143 [ _13 ]))) "j.C":72:17 discrim 1 5590
{pred_subrvvm8qi}
(expr_list:REG_DEAD (reg:SI 66 vl)
(expr_list:REG_DEAD (reg:SI 67 vtype)
(nil
The first thing that popped out to me was the hard register usage for the
output. That's because the output is used as an argument. That led me to
realize that v8 is also holding live data. v0, of course, will be needed for
the mask. So to get a successful allocation with no reloading we'd have to
have tie one of the inputs with the output.
What we get instead from allocation is r135 in memory and r159 in v24. All
downhill from there.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #12 from Robin Dapp ---
Some "findings" below but I don't have the feeling I'm much closer to anything
actionable.
At some point we're trying to split a live range of an RVVM8QI register (v16,
hard regno = 112) for the reload insn
(insn 93 169 123 2 (set (reg:RVVM8QI 169 [orig:135 _4 ] [135])
(reg:RVVM8QI 241 [orig:135 _4 ] [135])) "pr115458.c":48:33 2726
{*movrvvm8qi_whole}
(nil))
In split_reg we have
mode = RVVM8QI
but
machine_mode reg_rtx_mode = GET_MODE (regno_reg_rtx[hard_regno]);
However reg_raw_mode[112] = RVVM1SF so
reg_rtx_mode = RVVM1SF.
As an RVVM8QI access to RVVM1SF constitutes a paradoxical subreg we change the
mode to RVVM1SF and eventually create a spill/save
(insn 174 0 0 (set (reg:RVVM1SF 247)
(reg:RVVM1SF 112 v16)) -1
(nil))
This happens for all hard regs of RVVM8QI individually (v16 - v23), same for
the restore of course.
As a data point: When prohibiting this mode change and just keeping RVVM8QI we
compile successfully and we barely need to reload at all.
However, reg_rtx_mode[112] = RVVM1SF without the vector ABI so, while odd, it's
not the real culprit.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #11 from Jeffrey A. Law --- Hmm. Are we somehow mis-computing the size of the mask operand thinking it takes v0..v7 in the LMUL8 scenario? If so that would mean this instruction consumes the entire vector register file. In isolation that should be manageable, but it may become problematical if we have to do any spilling. I guess the first question is why did we spill. Does the .reload dump file give any good clues? Do we perhaps re-use the mask and end up with crossing lifetimes for the mask?
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #10 from Robin Dapp ---
It's also odd to see single-register spills for an LMUL8 register group, that
doesn't seem right.
(insn 174 169 180 2 (set (reg:RVVM1SF 247)
(reg:RVVM1SF 112 v16)) "pr115458.c":48:33 2749 {*movrvvm1sf_whole}
(expr_list:REG_DEAD (reg:RVVM1SF 112 v16)
(nil)))
(insn 180 174 186 2 (set (reg:RVVM1SF 250)
(reg:RVVM1SF 113 v17)) "pr115458.c":48:33 2749 {*movrvvm1sf_whole}
(expr_list:REG_DEAD (reg:RVVM1SF 113 v17)
(nil)))
...
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #9 from Robin Dapp --- Bisecting further only leads to the commit that introduced the vector ABI. Comparing the dumps with and without vector ABI is very tedious because a lot of things differ. It looks like we cannot create a reload for a masked sub vsub v8,v16,v24,v0.t (which already uses all available LMUL=8 hard regs). This insn is being inlined and disabling inlining gets rid of the ICE. I don't yet understand how the ABI changes spilling possibilities here.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 Palmer Dabbelt changed: What|Removed |Added CC||palmer at gcc dot gnu.org --- Comment #8 from Palmer Dabbelt --- (In reply to Jeffrey A. Law from comment #7) > Bisection of the reduced case landed here for me: > > commit acc22d56e140220e7dc6c138918cb6754b6d1c0b (HEAD) > Author: Yanzhang Wang > Date: Thu Jan 25 21:06:09 2024 +0800 > > RISC-V: remove param riscv-vector-abi. [PR113538] > > Also adjust some of the tests for scan-assembly. The behavior is the > same as --param=riscv-vector-abi before. > > gcc/ChangeLog: > > PR target/113538 > * config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag. > (riscv_fntype_abi): Ditto. > * config/riscv/riscv.opt: Ditto. > [ ... ] We were chatting about this in the patchwork sync, just writing it here in case anyone is watching the bug. This one isn't quite a non-functional change (even though it sort of looks like one): before the change the default behavior is to disable the vector ABI, after the change it's enabled by default. There's some functions with vector arguments in here, so this patch should change the behavior. A more interesting patch might show up bisecting with `--param=riscv-vector-abi` enabled.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #7 from Jeffrey A. Law --- Bisection of the reduced case landed here for me: commit acc22d56e140220e7dc6c138918cb6754b6d1c0b (HEAD) Author: Yanzhang Wang Date: Thu Jan 25 21:06:09 2024 +0800 RISC-V: remove param riscv-vector-abi. [PR113538] Also adjust some of the tests for scan-assembly. The behavior is the same as --param=riscv-vector-abi before. gcc/ChangeLog: PR target/113538 * config/riscv/riscv.cc (riscv_get_arg_info): Remove the flag. (riscv_fntype_abi): Ditto. * config/riscv/riscv.opt: Ditto. [ ... ]
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458
--- Comment #6 from Jeffrey A. Law ---
Heavily reduced testcase. -O2 -fpermissive -fno-exceptions -std=c++17
-march=rv64gcv -mabi=lp64d
typedef char int8_t;
typedef unsigned char uint8_t;
template using MakeUnsigned = unsigned char;
#pragma riscv intrinsic "vector"
template struct Simd {
using T = int;
template using Rebind = Simd;
};
template struct ClampNAndPow2 {
using type = Simd;
};
template struct ScalableTagChecker {
using type = typename ClampNAndPow2::type;
};
template struct CappedTagChecker {
using type = typename ClampNAndPow2::type;
};
template
using ScalableTag = typename ScalableTagChecker::type;
template
using CappedTag = typename CappedTagChecker::type;
template using TFromD = typename D::T;
template using Rebind = typename D::Rebind;
template using RebindToUnsigned = Rebind, D>;
template struct DFromV_t;
template using DFromV = typename DFromV_t::type;
template <> struct DFromV_t {
using Lane = int8_t;
using type = ScalableTag;
};
template void Lanes(Simd);
template vuint8m8_t Set(Simd, uint8_t arg) {
return __riscv_vmv_v_x_u8m8(arg, 0);
}
template vint8m8_t Set(Simd, int8_t);
template using VFromD = decltype(Set(D(), TFromD()));
template VFromD Zero(D d) {
RebindToUnsigned du;
return BitCast(d, Set(du, 0));
}
template vint8m8_t BitCastFromByte(Simd, vuint8m8_t v) {
return __riscv_vreinterpret_v_u8m8_i8m8(v);
}
template VFromD BitCast(D d, FromV v) {
return BitCastFromByte(d, v);
}
vint8m8_t MaskedSubOr(vint8m8_t no, vbool1_t m, vint8m8_t a, vint8m8_t b) {
return __riscv_vsub_vv_i8m8_mu(m, no, a, b, 0);
}
vbool1_t Lt(vint8m8_t a, vint8m8_t b) {
return __riscv_vmslt_vv_i8m8_b1(a, b, 0);
}
template V InterleaveUpper(D, V, V);
template using Vec = decltype(Zero(D()));
template V IfNegativeThenNegOrUndefIfZero(V mask, V v) {
auto zero = Zero(DFromV());
return MaskedSubOr(v, Lt(mask, zero), zero, v);
}
template Vec PositiveIota(D);
template void AssertVecEqual(D, Vec, Vec);
template struct ForeachCappedR {
static Do(long, long) {
CappedTag d;
Test()(T(), d);
}
};
template
TestMoreThan1LaneIfNegativeThenNegOrUndefIfZero(D d, Vec v2) {
Vec v1, v4;
Lanes(d);
Vec v8 = InterleaveUpper(d, v2, v1);
AssertVecEqual(d, v8, IfNegativeThenNegOrUndefIfZero(v4, v8));
Vec zero(IfNegativeThenNegOrUndefIfZero(v4, zero));
AssertVecEqual(d, zero, IfNegativeThenNegOrUndefIfZero(v8, zero));
}
struct TestIfNegativeThenNegOrUndefIfZero {
template operator()(T, D d) {
auto v1 = PositiveIota(d), v2(v1), zero = Zero(d), vmin = Set(d, 0),
vmax(IfNegativeThenNegOrUndefIfZero(vmin, v1));
AssertVecEqual(d, zero, zero);
AssertVecEqual(d, v2, IfNegativeThenNegOrUndefIfZero(vmax, v2));
TestMoreThan1LaneIfNegativeThenNegOrUndefIfZero(d, v2);
}
};
template struct ForExtendableVectors {
template operator()(T) {
constexpr kMaxCapped(sizeof(T));
long max_lanes;
constexpr long kMul = kMaxCapped;
ForeachCappedR::Do(
1, max_lanes);
}
};
struct {
operator()(char t) { ForExtendableVectors<0>()(t); }
} ForSignedTypes_func;
ForSignedTypes() { ForSignedTypes_func(int8_t()); }
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 Richard Biener changed: What|Removed |Added Keywords||needs-reduction Last reconfirmed|2024-06-14 00:00:00 |2024-10-14 Priority|P3 |P1
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 --- Comment #5 from Li Pan --- (In reply to Richard Biener from comment #4) > The bisected rev only exposes this. Thanks Richard for hint, will take a look into it.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #4 from Richard Biener --- The bisected rev only exposes this.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-06-14 Summary|[15 regression] [RISC-V]|[15 regression] [RISC-V] |ICE in |ICE in |lra_split_hard_reg_for, at |lra_split_hard_reg_for, at |lra-assigns.cc:1868 unable |lra-assigns.cc:1868 unable |to find a register to spill |to find a register to spill ||since ||r15-518-g99b1daae18c095
