Hi Richard,
On 2026-02-18 13:56, Richard Earnshaw (foss) wrote:
On 17/02/2026 13:09, Torbjorn SVENSSON wrote:
Hi,
Can this be picked to releases/gcc-15?
In order for it to apply more cleanly, I would like to also pick
r16-3492-g3cb6c01d2a9ab0 and r16-7262-gf7f2b73b9c1e01.
OK
I did another run over the night and that was a good thing.
I discovered a few new failures that I missed last time.
This would be fixed by also picking r16-5053-gc35bab08191134.
FAIL: gcc.target/arm/attr-neon.c scan-assembler-times .fpu\\s+neon\n 1
These all also xpass'es on trunk for Cortex-M0 (verified with
r16-7367-g7b2e9d01d325f0).
Reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124166
XPASS: gcc.dg/vect/vect-cond-1.c -flto -ffat-lto-objects scan-tree-dump-times vect
"OUTER LOOP VECTORIZED" 1
XPASS: gcc.dg/vect/vect-cond-1.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
XPASS: gcc.dg/vect/vect-cond-3.c -flto -ffat-lto-objects scan-tree-dump-times vect
"OUTER LOOP VECTORIZED" 1
XPASS: gcc.dg/vect/vect-cond-3.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
XPASS: gcc.dg/vect/vect-cond-4.c -flto -ffat-lto-objects scan-tree-dump-times vect
"OUTER LOOP VECTORIZED" 1
XPASS: gcc.dg/vect/vect-cond-4.c scan-tree-dump-times vect "OUTER LOOP
VECTORIZED" 1
These two also fail on trunk for all of my tested Cortex-M and Cortex-A targets
(verified with r16-7367-g7b2e9d01d325f0).
Reported in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124164
FAIL: gcc.dg/vect/complex/fast-math-complex-mls-float.c -flto -ffat-lto-objects
scan-tree-dump vect "Found COMPLEX_ADD_ROT270"
FAIL: gcc.dg/vect/complex/fast-math-complex-mls-float.c scan-tree-dump vect "Found
COMPLEX_ADD_ROT270"
These two would be fixed by also picking r16-7207-g9dceb52664d5af.
FAIL: gcc.dg/vect/complex/fast-math-complex-mls-half-float.c -flto -ffat-lto-objects
scan-tree-dump vect "Found COMPLEX_ADD_ROT270"
FAIL: gcc.dg/vect/complex/fast-math-complex-mls-half-float.c scan-tree-dump vect
"Found COMPLEX_ADD_ROT270"
I've launched another test run with r16-5053-gc35bab08191134 and
r16-7207-g9dceb52664d5af picked on top of the other 3 patches originally
requested to be picked. If there is no new failure, are also these 2 commits
okay to be picked for release/gcc-15?
Kind regards,
Torbjörn
R.
Kind regards,
Torbjörn
On 2026-01-29 18:30, Richard Earnshaw wrote:
Several target-supports checks for Arm are still using the antiquated
-mfpu=... setting rather than picking up FPU extensions via the
architecture specification. This causes problems when tests are
layered because they do not consistently override each other.
Arguably, that is incorrect anyway: you can't test two sets of flag
combinations independently and then expect to be able to apply both
of them, but this change at least makes this behave in a reasonable
way provided the second set of flags fully overrides the first.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp:
(check_effective_target_arm_v8_3a_complex_neon_ok_nocache):
Split and fill in arm and aarch64 compile options. Remove the
cpu_unset variable.
(check_effective_target_arm_v8_2a_fp16_neon_ok_nocache): Likewise.
(check_effective_target_arm_v8_3a_fp16_complex_neon_ok_nocache):
Likewise.
(check_effective_target_arm_neon_ok_nocache): Rework to use
-mfpu=auto.
(check_effective_target_arm_neon_fp16_ok_nocache): Likewise.
