Re: [Linaro-TCWG-CI] gcc-16-6952-g14cd2833b27a: 7 regressions on master-thumb_v8a_hard_eabi
The test fails on arm-eabi when testing with the following settings: -mlittle-endian -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=vfpv3
It only fails in the following torture option set: -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
It also fails on numerous other 32-bit targets, but it depends on how the memcpy-like loop gets vectorized and unrolled.
I hope we can live with the XPASSes.
On Apr 11, 2026, ci_notify@linaro.org wrote:
Dear contributor, Our automatic CI has detected problems related to your patch(es). Please find some details below.
In arm-eabi thumb v8-a hard, after: | commit gcc-16-6952-g14cd2833b27a | Author: Alexandre Oliva oliva@adacore.com | Date: Wed Jan 21 00:30:24 2026 -0300 | | testsuite: tolerate bogus warning in pr113026-1.c [PR113524] | | The bogus warning in pr113026-1.c is issued at some optimization | levels on various 32-bit targets. | | ... 6 lines of the commit log omitted.
Produces 7 regressions: | | regressions.sum: | Running gcc:gcc.dg/torture/dg-torture.exp ... | XPASS: gcc.dg/torture/pr113026-1.c -O0 PR118504 (test for bogus messages, line 12) | XPASS: gcc.dg/torture/pr113026-1.c -O1 PR118504 (test for bogus messages, line 12) | XPASS: gcc.dg/torture/pr113026-1.c -O2 PR118504 (test for bogus messages, line 12) | XPASS: gcc.dg/torture/pr113026-1.c -O2 -flto | -fno-use-linker-plugin -flto-partition=none PR118504 (test for | bogus messages, line 12) | ... and 3 more
Used configuration : *CI config* tcwg_gnu_embed_check_gcc arm-eabi -mthumb -march=armv8-a+simd -mfpu=auto -mfloat-abi=hard *configure and test flags:* --target arm-eabi --disable-multilib --with-mode=thumb --with-arch=armv8-a+simd --with-fpu=crypto-neon-fp-armv8 --with-float=hard --target_board=-mthumb/-march=armv8-a+simd/-mfpu=auto/-mfloat-abi=hard qemu_cpu=any
We track this bug report under https://linaro.atlassian.net/browse/GNU-1870. Please let us know if you have a fix.
If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in
http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha... The full lists of regressions and improvements as well as configure and make commands are in
http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha... The list of [ignored] baseline and flaky failures are in
http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha...
Current build : http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha... Reference build : http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha...
Instruction to reproduce the build : https://gitlab.com/LinaroLtd/tcwg/ci/interesting-commits/-/raw/master/gcc/sh...
Full commit : See in git+ssh://linaroci@gcc.gnu.org/git/gcc.git
On 4/16/26 06:41, Alexandre Oliva via Gcc-regression wrote:
The test fails on arm-eabi when testing with the following settings: -mlittle-endian -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=vfpv3
It only fails in the following torture option set: -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
Isn't that combination excluded by /* { dg-skip-if "" { *-*-* } { "-ftracer" } { "" } } */ at the beginning of the testcase?
It also fails on numerous other 32-bit targets, but it depends on how the memcpy-like loop gets vectorized and unrolled.
I hope we can live with the XPASSes.
I suppose so.
That being said, I see this test PASS on all arm-*-eabi versions I am testing: -marm/-march=armv7-a/-mfpu=auto/-mfloat-abi=soft -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp -mthumb/-march=armv6s-m/-mtune=cortex-m0/-mfloat-abi=soft/-mfpu=autp -mthumb/-march=armv8-m.base/-mtune=cortex-m23/-mfloat-abi=soft/-mfpu=auto -mthumb/-march=armv7-m/-mtune=cortex-m3/-mfloat-abi=softfp -mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto -mthumb/-march=armv7e-m+fp/-mtune=cortex-m4/-mfloat-abi=hard/-mfpu=auto -mthumb/-march=armv8.1-m.main+mve.fp+fp.dp/-mtune=cortex-m55/-mfloat-abi=hard/-mfpu=auto -mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto -mthumb/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp -mthumb/-march=armv8-a+simd/-mfpu=auto/-mfloat-abi=hard
I see one failure: FAIL: gcc.dg/torture/pr113026-1.c -O3 -g (test for bogus messages, line 12)
on armeb-none-eabi with -marm/-march=armv7-a/-mfpu=neon/-mfloat-abi=hard
on arm-linux-gnueabihf and armeb-linux-gnueabihf the tests PASS.
In summary on arm-*-eabi for RUNTESTFLAGS=dg-torture.exp=pr113026-1.c with your patch I have now 7 PASS + 7 XPASS + 1 UNSUPPORTED while I had 14 PASS + 1 UNSUPPORTED without your patch.
Thanks,
Christophe
On Apr 11, 2026, ci_notify@linaro.org wrote:
Dear contributor, Our automatic CI has detected problems related to your patch(es). Please find some details below.
In arm-eabi thumb v8-a hard, after: | commit gcc-16-6952-g14cd2833b27a | Author: Alexandre Oliva oliva@adacore.com | Date: Wed Jan 21 00:30:24 2026 -0300 | | testsuite: tolerate bogus warning in pr113026-1.c [PR113524] | | The bogus warning in pr113026-1.c is issued at some optimization | levels on various 32-bit targets. | | ... 6 lines of the commit log omitted.
Produces 7 regressions: | | regressions.sum: | Running gcc:gcc.dg/torture/dg-torture.exp ... | XPASS: gcc.dg/torture/pr113026-1.c -O0 PR118504 (test for bogus messages, line 12) | XPASS: gcc.dg/torture/pr113026-1.c -O1 PR118504 (test for bogus messages, line 12) | XPASS: gcc.dg/torture/pr113026-1.c -O2 PR118504 (test for bogus messages, line 12) | XPASS: gcc.dg/torture/pr113026-1.c -O2 -flto | -fno-use-linker-plugin -flto-partition=none PR118504 (test for | bogus messages, line 12) | ... and 3 more
Used configuration : *CI config* tcwg_gnu_embed_check_gcc arm-eabi -mthumb -march=armv8-a+simd -mfpu=auto -mfloat-abi=hard *configure and test flags:* --target arm-eabi --disable-multilib --with-mode=thumb --with-arch=armv8-a+simd --with-fpu=crypto-neon-fp-armv8 --with-float=hard --target_board=-mthumb/-march=armv8-a+simd/-mfpu=auto/-mfloat-abi=hard qemu_cpu=any
We track this bug report under https://linaro.atlassian.net/browse/GNU-1870. Please let us know if you have a fix.
If you have any questions regarding this report, please ask on linaro-toolchain@lists.linaro.org mailing list.
-----------------8<--------------------------8<--------------------------8<--------------------------
The information below contains the details of the failures, and the ways to reproduce a debug environment:
You can find the failure logs in *.log.1.xz files in
http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha... The full lists of regressions and improvements as well as configure and make commands are in
http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha... The list of [ignored] baseline and flaky failures are in
http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha...
Current build : http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha... Reference build : http://54.172.246.49:9090/jobs/tcwg_gnu_embed_check_gcc--master-thumb_v8a_ha...
Instruction to reproduce the build : https://gitlab.com/LinaroLtd/tcwg/ci/interesting-commits/-/raw/master/gcc/sh...
Full commit : See in git+ssh://linaroci@gcc.gnu.org/git/gcc.git
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Apr 16, 2026, Christophe Lyon christophe.lyon@arm.com wrote:
On 4/16/26 06:41, Alexandre Oliva via Gcc-regression wrote:
The test fails on arm-eabi when testing with the following settings: -mlittle-endian -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=vfpv3
It only fails in the following torture option set: -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
Isn't that combination excluded by /* { dg-skip-if "" { *-*-* } { "-ftracer" } { "" } } */ at the beginning of the testcase?
Aah. Yeah, I suppose in gcc-16 it does. I was looking at gcc-15 sources and results, without realizing there was a different fix in gcc-16 for the problem I observed in gcc-15.
I guess I should revert my change and take that one and see how it goes in our gcc-15 builds. I'm fine with reverting my seemingly redundant change in gcc-16; should I?
Speaking of regressions... I see some target-supports arm/aarch64 neon changes made gcc-15 a little over a week ago, along with my fast-math-complex-mls-half-float.c xfail for COMPLEX_ADD_ROT270.
Since those backports, I'm seeing fast-math-complex-mls-{float,double}.c fail on arm/aarch64 systems where they're not skipped any more, and regression on arm due to command line options changes brought about by those backports.
In both cases, the failure mode I'd observed in -half-float.c, namely reassoc making ROT270 unrecognizable, now affects float and double as well.
I wonder if you're getting that too. I intend to propose a similar xfail for them, but it would suck if that brought you more unwanted XPASSes.
On 4/17/26 06:30, Alexandre Oliva wrote:
On Apr 16, 2026, Christophe Lyon christophe.lyon@arm.com wrote:
On 4/16/26 06:41, Alexandre Oliva via Gcc-regression wrote:
The test fails on arm-eabi when testing with the following settings: -mlittle-endian -mfloat-abi=hard -mcpu=cortex-a9 -mfpu=vfpv3
It only fails in the following torture option set: -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
Isn't that combination excluded by /* { dg-skip-if "" { *-*-* } { "-ftracer" } { "" } } */ at the beginning of the testcase?
Aah. Yeah, I suppose in gcc-16 it does. I was looking at gcc-15 sources and results, without realizing there was a different fix in gcc-16 for the problem I observed in gcc-15.
I guess I should revert my change and take that one and see how it goes in our gcc-15 builds. I'm fine with reverting my seemingly redundant change in gcc-16; should I?
I think so, but since IIUC you checked on gcc-15, please check on trunk too before committing the revert. But maybe we want a partial backport of r16-5911-g7dd39924c9a696 to gcc-15?
Speaking of regressions... I see some target-supports arm/aarch64 neon changes made gcc-15 a little over a week ago, along with my fast-math-complex-mls-half-float.c xfail for COMPLEX_ADD_ROT270.
Since those backports, I'm seeing fast-math-complex-mls-{float,double}.c fail on arm/aarch64 systems where they're not skipped any more, and regression on arm due to command line options changes brought about by those backports.
In both cases, the failure mode I'd observed in -half-float.c, namely reassoc making ROT270 unrecognizable, now affects float and double as well.
I wonder if you're getting that too. I intend to propose a similar xfail for them, but it would suck if that brought you more unwanted XPASSes.
At the moment on both trunk and gcc-15 I see: 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" XFAIL: gcc.dg/vect/complex/fast-math-complex-mls-half-float.c -flto -ffat-lto-objects scan-tree-dump vect "Found COMPLEX_ADD_ROT270" XFAIL: gcc.dg/vect/complex/fast-math-complex-mls-half-float.c scan-tree-dump vect "Found COMPLEX_ADD_ROT270" UNSUPPORTED: gcc.dg/vect/complex/fast-math-complex-mls-double.c UNSUPPORTED: gcc.dg/vect/complex/fast-math-complex-mls-double.c -flto -ffat-lto-objects
There's PR116463 and a few others related to this.
Thanks,
Christophe
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
linaro-toolchain@lists.linaro.org
-
Alexandre Oliva -
Christophe Lyon