[Bug c/109087] New: csmith: end of year runtime bug ?

[Bug c/109087] New: csmith: end of year runtime bug ?

[dcb314 at hotmail dot com]

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

            Bug ID: 109087
           Summary: csmith: end of year runtime bug ?
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 54633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54633&action=edit
C source code

For the attached C code, compiled with -w -ftrivial-auto-var-init=zero -g -O3
-march=znver3 -fno-strict-aliasing and various versions of gcc trunk, does
this:

/home/dcb36/gcc/results.20221002/bin/gcc
checksum = C05B4B46
/home/dcb36/gcc/results.20221101/bin/gcc
checksum = C05B4B46
/home/dcb36/gcc/results.20221201/bin/gcc
checksum = C05B4B46
/home/dcb36/gcc/results.20230101/bin/gcc
Segmentation fault (core dumped)
/home/dcb36/gcc/results.20230209.asan.ubsan/bin/gcc
Segmentation fault (core dumped)

[Bug c/109087] csmith: end of year runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
Git range seems to be g:d0a3d55ae4a2656f .. g:4f1314f547f69d3a, which is about
533 commits. 

Trying a bisect.

[Bug c/109087] csmith: end of year runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
Git range seems to be g:a996888327c2248b .. g:4f1314f547f69d3a,
which is 134 commits.

[Bug c/109087] csmith: end of year runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
Git range now seems to be g:a996888327c2248b .. g:0cb5d7cdbab8e5f8,
which is 33 commits.

[Bug c/109087] csmith: end of year runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Git range seems to be g:37d8312f560f1e2f .. g:0cb5d7cdbab8e5f8,
which is 9 commits.

No hot candidate yet.

[Bug c/109087] csmith: end of year runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
First bad commit seems to be:

eef81eefcdc2a58111e50eb2162ea1f5becc8004 is the first bad commit
commit eef81eefcdc2a58111e50eb2162ea1f5becc8004
Author: Jan Hubicka <jh@suse.cz>
Date:   Thu Dec 22 10:55:46 2022 +0100

    Zen4 tuning part 2

which seems a bit odd, as I am on zen3. However:

$ source ./qwe.sh
/home/dcb36/gcc/results.bbe04bade0cc3b17/bin/gcc
checksum = C05B4B46
/home/dcb36/gcc/results.924033e39bd440ca/bin/gcc
checksum = C05B4B46
/home/dcb36/gcc/results.eef81eefcdc2a581/bin/gcc
Segmentation fault (core dumped)
$

[Bug c/109087] [13 Regression] csmith: end of year runtime bug ?

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
            Summary|csmith: end of year runtime |[13 Regression] csmith: end
                   |bug ?                       |of year runtime bug ?
           Keywords|                            |wrong-code

[Bug target/109087] [13 Regression] csmith: end of year runtime bug ?

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org
             Target|                            |x86_64-*-*
          Component|c                           |target

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Try -fno-tree-vectorize?

[Bug target/109087] [13 Regression] csmith: end of year runtime bug ?

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-03-10
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
With gcc pr109087.c -w -ftrivial-auto-var-init=zero -g -O3 -march=znver3
-fno-strict-aliasing -fno-tree-vectorize -fno-tree-slp-vectorize
it started with r13-4839-geef81eefcdc2a581. That's strange, because I
intentionally disable the vectorizer.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #7)
> With gcc pr109087.c -w -ftrivial-auto-var-init=zero -g -O3 -march=znver3
> -fno-strict-aliasing -fno-tree-vectorize -fno-tree-slp-vectorize
> it started with r13-4839-geef81eefcdc2a581. That's strange, because I
> intentionally disable the vectorizer.

Could be exposed by the change to ix86_expand_set_or_cpymem or
ix86_reassociation_width then.

Or the change to X86_TUNE_AVX256_MOVE_BY_PIECES,
X86_TUNE_AVX256_STORE_BY_PIECES which adds znver3 to them ...

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Richard Biener from comment #6)
> Try -fno-tree-vectorize?

I tried that, and it made no difference at all.

I also tried dropping the -march= setting back to znver1 and
that also made no difference.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David Binderman from comment #9)
> (In reply to Richard Biener from comment #6)
> > Try -fno-tree-vectorize?
> 
> I tried that, and it made no difference at all.
> 
> I also tried dropping the -march= setting back to znver1 and
> that also made no difference.

The change added znver1/2/3 to X86_TUNE_AVX256_MOVE_BY_PIECES,
X86_TUNE_AVX256_STORE_BY_PIECES also so must be related to that ...

Most likely a latent bug too ...

you might get a similar failure on alderlake or core_avx2 too.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems to be exact same thing as I've just described in PR109093.
.DEFERRED_INIT isn't for whatever reason optimized away, expansion decides to
use vector  memset for it and somehow during pro_and_epilogue the memory slot
for the variable isn't appropriately aligned.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As for the .DEFERRED_INIT not being DSEd when it isn't used, cvise reduced
testcase is e.g.

int a;
int foo (void);
int bar (void);

void
baz (void)
{
  int *b[6];
  if (foo ())
    a |= bar ();
}

while with a |= 1; instead dse1 removes it.  Richi, any thoughts on that?
Of course, the real bug is on the x86 backend side.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #12)
> As for the .DEFERRED_INIT not being DSEd when it isn't used, cvise reduced
> testcase is e.g.
> 
> int a;
> int foo (void);
> int bar (void);
> 
> void
> baz (void)
> {
>   int *b[6];
>   if (foo ())
>     a |= bar ();
> }
> 
> while with a |= 1; instead dse1 removes it.  Richi, any thoughts on that?
> Of course, the real bug is on the x86 backend side.

The reason why we do not DSE the .DEFERRED_INIT is because of the VDEF->VUSE
walking limitation in dse_classify_store, in particular we fail to follow
the chain of VDEFs in BB3 when the uses are the one in the merge PHI in BB4
and the first call in BB3.

Fortunately for single-arg PHIs I've added proper handling for this and
this can be extended to cover this case.  I'm testing a patch, but not sure
if it's appropriate at this stage.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I didn't mean for GCC 13, we need to fix the actual backend bug regardless and
so a DSE improvement can't be considered a fix... ;)
Just the DSE thing happens very often with -ftrivial-auto-var-init=.
I wonder if even after your improvement we don't keep .DEFERRED_INIT for unused
vars for the case when the DSE walk will run into the vdef/vuse limits (I
assume it doesn't do unbounded walk).  Perhaps some special handling of
.DEFERRED_INITs for vars which have solely those statements and clobbers and
nothing else?

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 14 Mar 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109087
> 
> --- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I didn't mean for GCC 13, we need to fix the actual backend bug regardless and
> so a DSE improvement can't be considered a fix... ;)
> Just the DSE thing happens very often with -ftrivial-auto-var-init=.
> I wonder if even after your improvement we don't keep .DEFERRED_INIT for unused
> vars for the case when the DSE walk will run into the vdef/vuse limits (I
> assume it doesn't do unbounded walk).

Sure, it's still covered by the walking limit.

> Perhaps some special handling of
> .DEFERRED_INITs for vars which have solely those statements and clobbers and
> nothing else?

remove_unused_locals has code to handle vars only CLOBBEREd, so yes,
we can probably wire such a thing in there at the cost of one extra
walk (see the have_local_clobbers flag, the first walk discovers,
the second eventually removes them).

I'll see to draft a patch for this as well.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
I've pushed the more aggressive .DEFERRED_INIT removal so the issue might be
only latent now.

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the rest is discussed in PR109093...

[Bug target/109087] [13 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is true that with r13-6661 + r13-6691 this bug is just latent, so perhaps it
doesn't need to be P1 unless somebody comes up with a reproducer.

[Bug target/109087] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[13 Regression] csmith: end |csmith: end of year runtime
                   |of year runtime bug since   |bug since
                   |r13-4839-geef81eefcdc2a581  |r13-4839-geef81eefcdc2a581
           Priority|P1                          |P3

[Bug target/109087] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug target/109087] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug target/109087] [13/14/15 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:1e0ae1f52741f7e0133661659ed2d210f939a398

commit r15-571-g1e0ae1f52741f7e0133661659ed2d210f939a398
Author: Richard Biener <rguenther@suse.de>
Date:   Wed May 15 18:32:37 2024 +0200

    tree-optimization/79958 - make DSE track multiple paths

    DSE currently gives up when the path we analyze forks.  This leads
    to multiple missed dead store elimination PRs.  The following fixes
    this by recursing for each path and maintaining the visited bitmap
    to avoid visiting CFG re-merges multiple times.  The overall cost
    is still limited by the same bound, it's just more likely we'll hit
    the limit now.  The patch doesn't try to deal with byte tracking
    once a path forks but drops info on the floor and only handling
    fully dead stores in that case.

            PR tree-optimization/79958
            PR tree-optimization/109087
            PR tree-optimization/100314
            PR tree-optimization/114774
            * tree-ssa-dse.cc (dse_classify_store): New forwarder.
            (dse_classify_store): Add arguments cnt and visited, recurse
            to track multiple paths when we end up with multiple defs.

            * gcc.dg/tree-ssa/ssa-dse-48.c: New testcase.
            * gcc.dg/tree-ssa/ssa-dse-49.c: Likewise.
            * gcc.dg/tree-ssa/ssa-dse-50.c: Likewise.
            * gcc.dg/tree-ssa/ssa-dse-51.c: Likewise.
            * gcc.dg/graphite/pr80906.c: Avoid DSE of last data reference
            in loop.
            * g++.dg/ipa/devirt-24.C: Adjust for extra DSE.
            * g++.dg/warn/Wuninitialized-pr107919-1.C: Use more important
            -O2 optimization level, -O1 regresses.

[Bug target/109087] [13/14/15 Regression] csmith: end of year runtime bug since r13-4839-geef81eefcdc2a581

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
The missed DSE should be fixed, I'm not sure if the bogus .DEFERRED_INIT
expansion was?  Anyway, closing as that issue is discussed in PR109093.

*** This bug has been marked as a duplicate of bug 109093 ***