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.