[Bug tree-optimization/113539] New: [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[Bug tree-optimization/113539] New: [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

            Bug ID: 113539
           Summary: [14 Regression] perlbench miscompiled on aarch64 since
                    r14-8223-g1c1853a70f
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

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).

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tnfchris at gcc dot gnu.org

--- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
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?

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Tamar Christina <tnfchris at gcc dot gnu.org> 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 <tnfchris at gcc dot gnu.org> ---
(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

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

--- Comment #4 from Alex Coplan <acoplan at gcc dot gnu.org> ---
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

[liuhongt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Hongtao Liu <liuhongt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |liuhongt at gcc dot gnu.org

--- Comment #5 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
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

[fkastl at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Filip Kastl <fkastl at suse dot cz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fkastl at suse dot cz

--- Comment #6 from Filip Kastl <fkastl at suse dot cz> ---
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

[fkastl at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

--- Comment #7 from Filip Kastl <fkastl at suse dot cz> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
Does this still happen after r14-8413-g578c7b91f418eb?

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[fkastl at suse dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

--- Comment #9 from Filip Kastl <fkastl at suse dot cz> ---
(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

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So can we close this then?

[Bug tree-optimization/113539] [14 Regression] perlbench miscompiled on aarch64 since r14-8223-g1c1853a70f

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113539

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
oh forgot about this one, yes it's fixed now.  Nightlies are clean.