aboutsummaryrefslogtreecommitdiff
path: root/libgcc
diff options
context:
space:
mode:
authorRichard Sandiford <richard.sandiford@arm.com>2024-02-21 11:12:27 +0000
committerRichard Sandiford <richard.sandiford@arm.com>2024-02-21 11:12:27 +0000
commitad4df8cd080c9be738f61b5e91cc70a594c4419d (patch)
treeb9ac220adff1ff66065a04db6cef078cf49c31d2 /libgcc
parent4f7d4a2cd26673887f45e994a2f367a5c8fcc691 (diff)
downloadgcc-ad4df8cd080c9be738f61b5e91cc70a594c4419d.zip
gcc-ad4df8cd080c9be738f61b5e91cc70a594c4419d.tar.gz
gcc-ad4df8cd080c9be738f61b5e91cc70a594c4419d.tar.bz2
aarch64: Stack-clash prologues and VG saves [PR113995]
This patch fixes an ICE for a combination of: - -fstack-clash-protection - a frame that has SVE save slots - a frame that has no GPR save slots - a frame that has a VG save slot The allocation code was folding the SVE save slot allocation into the initial frame allocation, so that we had one allocation of size <size of SVE registers> + 16. But the VG save code itself expected the allocations to remain separate, since it wants to store at a constant offset from SP or FP. The VG save isn't shrink-wrapped and so acts as a probe of the initial allocations. It should therefore be safe to keep separate allocations in this case. The scans in locally_streaming_1.c expect no stack clash protection, so the patch forces that and adds a separate compile-only test for when protection is enabled. gcc/ PR target/113995 * config/aarch64/aarch64.cc (aarch64_expand_prologue): Don't fold the SVE allocation into the initial allocation if the initial allocation includes a VG save. gcc/testsuite/ PR target/113995 * gcc.target/aarch64/sme/locally_streaming_1.c: Require -fno-stack-clash-protection. * gcc.target/aarch64/sme/locally_streaming_1_scp.c: New test.
Diffstat (limited to 'libgcc')
0 files changed, 0 insertions, 0 deletions