https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114906
Bug ID: 114906
Summary: aarch64 locally_streaming ICE in
aarch64_expand_prologue
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: matmal01 at gcc dot gnu.org
Target Milestone: ---
Bug (testcase + ICE) below.
I believe this is because:
1) We save `r20` below `VG_REGNUM` in `aarch64_layout_frame` (and above the
point that `bytes_below_hard_fp` describes).
2) Despite that save of `r20` causing us to also set
`frame.wb_push_candidate1`, because we have a poly-int sized frame (due to the
-O0 in this case, but I don't think has to be -O0) we still end up in the
"General case" in `aarch64_layout_frame`.
3) Hence we end up with `initial_adjust` non zero, `sve_callee_adjust`
non-zero, and the `VG_REGNUM` not pointing to the same place as
`bytes_below_hard_fp` because there is that r20 saved in between.
My initial guess would be that we should simply change the assertion that
failed to check that VG_REGNUM is *greater than or equal to* `bytes_below_sp`.
To be honest I'm not entirely sure what this assertion is there for so would
not like to actually make that suggestion. The commit message of ad4df8cd080c
seems to say the assertion is there to ensure that the allocation of VG_REGNUM
is not folded into the initial_allocation, but I don't 100% follow what's going
on.
vshcmd: > cat ../streaming-prologues.c
[[arm::locally_streaming]] void
with_callee_saved_regs (__SVBool_t x)
{
asm ("" : : : "r20");
}
testing [14:47:20] $
vshcmd: > ${install_dir}/aarch64-none-linux-gnu-gcc \
vshcmd: > ../streaming-prologues.c \
vshcmd: > -fdiagnostics-plain-output -O0 -fstack-clash-protection \
vshcmd: > -march=armv9-a+sme -mtune=generic -moverride=tune=none \
vshcmd: > -S -o prologues-with-streaming-1.s
> > > > during RTL pass: late_pro_and_epilogue
> > > >
> > > >
> > > >
> > > >
../streaming-prologues.c: In function ‘with_callee_saved_regs’:
../streaming-prologues.c:5:1: internal compiler error: in
aarch64_expand_prologue, at config/aarch64/aarch64.cc:9705
0x142e3af aarch64_expand_prologue()
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/config/aarch64/aarch64.cc:9701
0x1a7eee7 gen_prologue()
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/config/aarch64/aarch64.md:1008
0x140219f target_gen_prologue
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/config/aarch64/aarch64.md:8121
0xb8d242 make_prologue_seq
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:5818
0xb8d3aa thread_prologue_and_epilogue_insns()
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:6053
0xb8dc4e rest_of_handle_thread_prologue_and_epilogue
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:6567
0xb8dcbf execute
/workspace/GNU-toolchain/fsf-trunk/src/gcc/gcc/function.cc:6692
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
testing [14:47:22] $
