Re: [Linaro-TCWG-CI] gcc-16-6952-g14cd2833b27a: 7 regressions on master-thumb_v8a_hard_eabi

On Apr 16, 2026, Christophe Lyon <[email protected]> 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.

-- 
Alexandre Oliva, happy hacker            https://blog.lx.oliva.nom.br/
Free Software Activist     FSFLA co-founder     GNU Toolchain Engineer
More tolerance and less prejudice are key for inclusion and diversity.
Excluding neuro-others for not behaving ""normal"" is *not* inclusive!