[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 Tamar Christina changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Tamar Christina --- oh forgot about this one, yes it's fixed now. Nightlies are clean.
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- So can we close this then?
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 --- Comment #9 from Filip Kastl --- (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.
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 --- Comment #8 from Richard Biener --- Does this still happen after r14-8413-g578c7b91f418eb?
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 --- Comment #7 from Filip Kastl --- 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.
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 Filip Kastl changed: What|Removed |Added CC||fkastl at suse dot cz --- Comment #6 from Filip Kastl --- 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.
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #5 from Hongtao Liu --- 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.
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 --- Comment #4 from Alex Coplan --- Reproduces with just -O3 -fno-strict-aliasing FWIW, no LTO or -mcpu needed.
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 Tamar Christina changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-01-22 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #3 from Tamar Christina --- (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.
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #2 from Richard Biener --- 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).
[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- 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?
