https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124043
--- Comment #3 from Torbjorn SVENSSON <azoff at gcc dot gnu.org> ---
I've looked though my old logs, and the first failure was with 15.2.rel1 that I
tested back in January.
Prior to 15.2.rel1, the test was marked as unsupported.
I'll just focus on a single combination of flags and try to understand what is
going on. I'll focus here after on gcc.target/arm/crypto-vsha1cq_u32.c and
thumb/arch=armv7e-m/cpu=cortex-m4/float-abi=hard/fpu=fpv4-sp-d16.
In gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c, there is only one thing
that would make the test unsupported and that is:
/* { dg-require-effective-target arm_crypto_ok } */
As check_effective_target_arm_crypto_ok_nocache has not changed in the last
years, I think we can ignore this function.
check_effective_target_arm_crypto_ok_nocache also calls
check_effective_target_arm_v8_neon_ok and it was changed a few years back.
Time for the drum roll... The tests are active since r15-6163-ga2006457c67688
where I added "-mcpu=unset" here:
proc check_effective_target_arm_v8_neon_ok_nocache { } {
global et_arm_v8_neon_flags
set et_arm_v8_neon_flags ""
if { [check_effective_target_arm32] } {
foreach flags {"" "-mfloat-abi=softfp" "-mfpu=neon-fp-armv8"
"-mfpu=neon-fp-armv8 -mfloat-abi=softfp"} {
if { [check_no_compiler_messages_nocache arm_v8_neon_ok object {
#if __ARM_ARCH < 8
#error not armv8 or later
#endif
#include "arm_neon.h"
void
foo ()
{
__asm__ volatile ("vrintn.f32 q0, q0");
}
- } "$flags -march=armv8-a"] } {
+ } "$flags -mcpu=unset -march=armv8-a"] } {
set et_arm_v8_neon_flags $flags
return 1
}
}
}
return 0
}
So, to sum up.
I do not have a single run where this test passes.
In 15.[23].rel1, I see that the testcase is ran as:
/build/arm-gnu-toolchain-15.2.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c -mthumb
-march=armv7e-m+fp -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=auto
-fdiagnostics-plain-output -ansi -pedantic-errors -mfpu=crypto-neon-fp-armv8
-O3 -ffat-lto-objects -fno-ident -S -o crypto-vsha1cq_u32.s
Simplifying the command line a bit ends up with (although it feels strange to
use cortex-m4 with crypto-neon-fp-armv8):
/build/arm-gnu-toolchain-15.2.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c -mthumb
-mcpu=cortex-m4 -mfloat-abi=hard -mfpu=crypto-neon-fp-armv8 -O3 -fno-ident -S
-o crypto-vsha1cq_u32.s
Comparing 14.3.rel1 and 15.3.rel1 gives:
$ diff -U4 \
<(/build/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c
-mcpu=cortex-a53+crypto -mfloat-abi=hard -mfpu=crypto-neon-fp-armv8 -O3
-fno-ident -S -o - -marm) \
<(/build/arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c
-mcpu=cortex-a53+crypto -mfloat-abi=hard -mfpu=crypto-neon-fp-armv8 -O3
-fno-ident -S -o - -marm)
--- /dev/fd/63 2026-07-13 15:42:06.501007717 +0200
+++ /dev/fd/62 2026-07-13 15:42:06.502007717 +0200
@@ -56,10 +56,9 @@
foo_lane0:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
- vmov r3, s0 @ int
- vdup.32 q8, r3
+ vdup.32 q8, d0[0]
sha1c.32 q1, q8, q2
vmov q0, q1 @ v4si
bx lr
.size foo_lane0, .-foo_lane0
$ diff -U6 \
<(/build/arm-gnu-toolchain-14.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c
-mcpu=cortex-a53+crypto -mfloat-abi=hard -mfpu=crypto-neon-fp-armv8 -O3
-fno-ident -S -o - -mthumb) \
<(/build/arm-gnu-toolchain-15.3.rel1-x86_64-arm-none-eabi/bin/arm-none-eabi-gcc
/build/gcc_src/gcc/testsuite/gcc.target/arm/crypto-vsha1cq_u32.c
-mcpu=cortex-a53+crypto -mfloat-abi=hard -mfpu=crypto-neon-fp-armv8 -O3
-fno-ident -S -o - -mthumb)
--- /dev/fd/63 2026-07-13 15:45:25.376017125 +0200
+++ /dev/fd/62 2026-07-13 15:45:25.376017125 +0200
@@ -60,14 +60,13 @@
foo_lane0:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #16
vst1.64 {d0-d1}, [sp:64]
- ldr r3, [sp]
- vdup.32 q8, r3
+ vld1.32 {d16[], d17[]}, [sp]
sha1c.32 q1, q8, q2
vmov q0, q1 @ v4si
add sp, sp, #16
@ sp needed
bx lr
.size foo_lane0, .-foo_lane0
Bisecting when ldr+vdup.32 became vld1.32 gave me r15-1579-g792f97b44ffc5e.
Is it acceptable to mitigate the test failure by adding
-fno-late-combine-instructions, or is -flate-combine-instructions a desirable
option for the tests?
I've sent a patch with the extra option that appears to resolve the issues I've
seen: https://gcc.gnu.org/pipermail/gcc-patches/2026-July/723747.html
