On 19/02/2026 12:40, Torbjorn SVENSSON wrote: > 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? >
I'm not too keen with the way this is going. We seem to be building a tower of semi-random backports with little clear strategy. The lack of links to the original patch posts means I also need to do a lot of archaeology to find that information when trying to decide what is OK and what might be problematic. For example, r16-7207-g9dceb52664d5af seems to be independent of what's being changed here, so should be part of a separate request. Please can you provide a single clear list of which patches you're looking to backport along with links to the original reviews on the mailing list. R. > 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. >>>> >
