I'm seeing miscompares of perlbench (both from SPEC CPU 2006 and SPEC CPU 2017) on aarch64 with recent trunk changes, a bisect pointed to r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c : commit 1c1853a70f9422169190e65e568dcccbce02d95c Author: Richard Biener <rguenther@suse.de> Date: Thu Jan 18 10:22:34 2024 Fix memory leak in vect_analyze_loop_form The miscompares are with the checkspam.pl workload, I see: *** Miscompare of checkspam.2500.5.25.11.150.1.1.1.1.out I've seen this with: -flto=auto -fomit-frame-pointer -O3 -fno-strict-aliasing and various -mcpu options (at least -mcpu=cortex-a72 and -mcpu=neoverse-v1).
If that's the commit that's miscomparing then it's probably a bug in early-break vect. So I'll take a look. + if ((integer_zerop (may_be_zero) + || integer_nonzerop (may_be_zero) is odd though, isn't that basically accepting all values of may_be_zero?
It accepts all constant known may_be_zero - we can handle all of those later. I suspect this just triggers a latent issue (vectorizing now simply using a different exit as canonical in one case).
(In reply to Richard Biener from comment #2) > It accepts all constant known may_be_zero - we can handle all of those later. > > I suspect this just triggers a latent issue (vectorizing now simply using > a different exit as canonical in one case). Indeed, I'll take a look.
Reproduces with just -O3 -fno-strict-aliasing FWIW, no LTO or -mcpu needed.
502.gcc_r hangs after r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95cwhen compiled with -O3 -march=sapphirerapids or -O3 -march=znver4 -mprefer-vector-width=128(or 256). Not sure if they're the same issue.
I just reproduced the same issue on an x86_64 zen3 machine. Running both 500.perlbench_r and 400.perlbench with options -Ofast -march=native -mtune=native -g -flto=32 results in *** Miscompare of checkspam.2500.5.25.11.150.1.1.1.1.out That means this is probably not only an aarch64 issue.
Does this still happen after r14-8413-g578c7b91f418eb?
(In reply to Richard Biener from comment #8) > Does this still happen after r14-8413-g578c7b91f418eb? I think it doesn't happen anymore. I can confirm that both on aarch64 and zen3, both the SPEC2006 and SPEC2017, with -Ofast -march=native -mtune=native -flto perlbench compiles correctly now.
So can we close this then?
oh forgot about this one, yes it's fixed now. Nightlies are clean.