[Bug c/109780] New: csmith: runtime crash with -O2 -march=znver1

[Bug c/109780] New: csmith: runtime crash with -O2 -march=znver1

[dcb314 at hotmail dot com]

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

            Bug ID: 109780
           Summary: csmith: runtime crash with -O2 -march=znver1
           Product: gcc
           Version: unknown
            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 55023
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55023&action=edit
C source code

The attached C code seems to work fine with -O2:

$ ../results.20230507.asan.ubsan/bin/gcc -w -O2  bug916.c
$ ./a.out
checksum = 44DCF65B
$ 

But adding -march=znver1 seems to cause trouble:

$ ../results.20230507.asan.ubsan/bin/gcc -w -O2 -march=znver1  bug916.c
$ ./a.out
Segmentation fault (core dumped)
$ 

Adding the -fno-strict-aliasing flag doesn't seem to help:

$ ../results.20230507.asan.ubsan/bin/gcc -w -O2 -march=znver1
-fno-strict-aliasing  bug916.c
$ ./a.out
Segmentation fault (core dumped)
$ 

The bug seems to have existed for a while:

$ ../results.20230417/bin/gcc -w -O2 -march=znver1 -fno-strict-aliasing 
bug916.c
$ ./a.out
Segmentation fault (core dumped)
$

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
=> 0x0000000000402378 <func_36+136>:    vmovdqa %xmm3,(%r8)
   0x000000000040237d <func_36+141>:    vmovdqa %xmm2,0x10(%r8)
   0x0000000000402383 <func_36+147>:    neg    %r9
   0x0000000000402386 <func_36+150>:    vmovdqa %xmm2,0x20(%r8)
End of assembler dump.
(gdb) p $r8
$1 = 140737488346408
(gdb) p/x $r8
$2 = 0x7fffffffdd28

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I should mention there is no difference in the gimple dump between with and
without -march=znver1 .

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

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

--- Comment #3 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Works with -fstack-reuse=none. Somehow GCC is confused about stack layout in
func_36. It leaves rsp misaligned by 8 mod 16, but computes the base of l_814
for
__builtin_memset (&l_814, 0, 80) as if rsp is aligned mod 16.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |needs-bisection
             Target|                            |x86_64-*-*
            Version|unknown                     |14.0
   Last reconfirmed|                            |2023-05-09
     Ever confirmed|0                           |1

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Seems good with g:18547874ee205d83 dated 20220515 and bad with
g:73f7109ffb159302,
dated yesterday.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
Seems good at date 20221106, so the date range is [20221106..20230417].

Trying 20230205.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
Broken at 20230205, so range is now [20221106.. 20230205].

Trying snapshot 20221218

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #6)
> Broken at 20230205, so range is now [20221106.. 20230205].
> 
> Trying snapshot 20221218

That was good, so range is 20221218..20230108.

Trying snapshot 20230101.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman <dcb314 at hotmail dot com> ---
As far as the snapshots go, 20221218..20221225 seems to be the range.

In git, this is g:fd69977febf399d1992bbf8d66ae9170e0a4dc9f ..
g:febb58d28bfa4b544ec7ffec2d61f46d25205ff0, which is 123 commits.

Trying g:89ba8366fe12fd2d04535c99ba67f33d7e305132.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[marxin at gcc dot gnu.org]

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

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

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

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with zen tuning revision r13-4839-geef81eefcdc2a5.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[amonakov at gcc dot gnu.org]

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

--- Comment #10 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #9)
> Started with zen tuning revision r13-4839-geef81eefcdc2a5.

The issue is also reproducible with -march=haswell or -march=skylake, so you
can use those for further bisection.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Martin Liška from comment #9)
> > Started with zen tuning revision r13-4839-geef81eefcdc2a5.
> 
> The issue is also reproducible with -march=haswell or -march=skylake, so you
> can use those for further bisection.

With -march=skylake it began with r13-4124-g156f523f9582f1 and with
-march=haswell it started with the very same revision.

[Bug target/109780] csmith: runtime crash with -O2 -march=znver1

[amonakov at gcc dot gnu.org]

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

--- Comment #12 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Eh, that commit sneakily changed avx2 tuning without explaining that in the
Changelog. Anyway, it should possible to "workaround" that by compiling with

  -O2 -mavx2 -mtune=skylake-avx512

instead, in which case the bisect will likely point to commit 
r12-2666-g29f0e955c97 ("x86: Update piecewise move and store") (before that,
expansion of memcpy via store-by-pieces wouldn't use avx2).

Also, PR 109093 looks very related.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|csmith: runtime crash with  |[12/13/14 Regression]
                   |-O2 -march=znver1           |csmith: runtime crash with
                   |                            |-O2 -march=znver1

--- Comment #13 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
PR 109087 might also be solved by this.

Marking as 12/13/14 regression since this is reproducible with -O2 plus basic
-m flags, while earlier PRs also needed -ftrivial-auto-var-init and lost the
regression markers in the meanwhile.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.4

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #14 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Any clue about how to fix this?

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #15 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
attachment 54666 from PR109093 seems able to fix this.  Could we make it into
trunk and the release branches?

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[hjl.tools at gmail dot com]

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

--- Comment #16 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 55409
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55409&action=edit
A patch

I am stilling trying to find a small testcase.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #17 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #16)
> Created attachment 55409 [details]
> A patch
> 
> I am stilling trying to find a small testcase.

The patch triggers an ICE building Spidermonkey 115b9 (it segfaults with GCC
trunk because of some unaligned vmovdqa):

0x93297b ix86_finalize_stack_frame_flags
        ../../gcc/gcc/config/i386/i386.cc:8224
0x162064c ix86_expand_epilogue(int)
        ../../gcc/gcc/config/i386/i386.cc:9405
0x1b2e27f gen_epilogue()
        ../../gcc/gcc/config/i386/i386.md:17517
0x160a815 target_gen_epilogue
        ../../gcc/gcc/config/i386/i386.md:17013
0xf15e86 make_epilogue_seq
        ../../gcc/gcc/function.cc:5964
0xf15f8b thread_prologue_and_epilogue_insns()
        ../../gcc/gcc/function.cc:6046
0xf166c2 rest_of_handle_thread_prologue_and_epilogue
        ../../gcc/gcc/function.cc:6544
0xf166c2 execute
        ../../gcc/gcc/function.cc:6625

The code at i386.cc:8224 reads:

  if (crtl->stack_realign_finalized)
    {
      /* After stack_realign_needed is finalized, we can't no longer
         change it.  */
      gcc_assert (crtl->stack_realign_needed == stack_realign);
      return;
    }

I'm not sure if the assert should be dropped or it's more difficult.

Or can we just force to use unaligned vector moves for block operations until
we can find a better solution?  It's at least better than leaving the
vectorized block moving broken and forcing people trying to disable the
feature.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #18 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #17)
> (In reply to H.J. Lu from comment #16)
> > Created attachment 55409 [details]
> > A patch
> > 
> > I am stilling trying to find a small testcase.
> 
> The patch triggers an ICE building Spidermonkey 115b9 (it segfaults with GCC
> trunk because of some unaligned vmovdqa):

I mean, "GCC trunk and -O3 -march=tigerlake -mtune=tigerlake".

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Xi Ruoyao from comment #17)
> (In reply to H.J. Lu from comment #16)
> > Created attachment 55409 [details]
> > A patch
> > 
> > I am stilling trying to find a small testcase.
> 
> The patch triggers an ICE building Spidermonkey 115b9 (it segfaults with GCC
> trunk because of some unaligned vmovdqa):
> 
> 0x93297b ix86_finalize_stack_frame_flags
> 	../../gcc/gcc/config/i386/i386.cc:8224
> 0x162064c ix86_expand_epilogue(int)
> 	../../gcc/gcc/config/i386/i386.cc:9405
> 0x1b2e27f gen_epilogue()
> 	../../gcc/gcc/config/i386/i386.md:17517
> 0x160a815 target_gen_epilogue
> 	../../gcc/gcc/config/i386/i386.md:17013
> 0xf15e86 make_epilogue_seq
> 	../../gcc/gcc/function.cc:5964
> 0xf15f8b thread_prologue_and_epilogue_insns()
> 	../../gcc/gcc/function.cc:6046
> 0xf166c2 rest_of_handle_thread_prologue_and_epilogue
> 	../../gcc/gcc/function.cc:6544
> 0xf166c2 execute
> 	../../gcc/gcc/function.cc:6625
> 
> The code at i386.cc:8224 reads:
> 
>   if (crtl->stack_realign_finalized)
>     {
>       /* After stack_realign_needed is finalized, we can't no longer
>          change it.  */
>       gcc_assert (crtl->stack_realign_needed == stack_realign);
>       return;
>     }
> 
> I'm not sure if the assert should be dropped or it's more difficult.
> 
> Or can we just force to use unaligned vector moves for block operations
> until we can find a better solution?  It's at least better than leaving the
> vectorized block moving broken and forcing people trying to disable the
> feature.

Do you have a testcase?

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #20 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #19)
> (In reply to Xi Ruoyao from comment #17)
> > (In reply to H.J. Lu from comment #16)
> > > Created attachment 55409 [details]
> > > A patch
> > > 
> > > I am stilling trying to find a small testcase.
> > 
> > The patch triggers an ICE building Spidermonkey 115b9 (it segfaults with GCC
> > trunk because of some unaligned vmovdqa):
> > 
> > 0x93297b ix86_finalize_stack_frame_flags
> > 	../../gcc/gcc/config/i386/i386.cc:8224
> > 0x162064c ix86_expand_epilogue(int)
> > 	../../gcc/gcc/config/i386/i386.cc:9405
> > 0x1b2e27f gen_epilogue()
> > 	../../gcc/gcc/config/i386/i386.md:17517
> > 0x160a815 target_gen_epilogue
> > 	../../gcc/gcc/config/i386/i386.md:17013
> > 0xf15e86 make_epilogue_seq
> > 	../../gcc/gcc/function.cc:5964
> > 0xf15f8b thread_prologue_and_epilogue_insns()
> > 	../../gcc/gcc/function.cc:6046
> > 0xf166c2 rest_of_handle_thread_prologue_and_epilogue
> > 	../../gcc/gcc/function.cc:6544
> > 0xf166c2 execute
> > 	../../gcc/gcc/function.cc:6625
> > 
> > The code at i386.cc:8224 reads:
> > 
> >   if (crtl->stack_realign_finalized)
> >     {
> >       /* After stack_realign_needed is finalized, we can't no longer
> >          change it.  */
> >       gcc_assert (crtl->stack_realign_needed == stack_realign);
> >       return;
> >     }
> > 
> > I'm not sure if the assert should be dropped or it's more difficult.
> > 
> > Or can we just force to use unaligned vector moves for block operations
> > until we can find a better solution?  It's at least better than leaving the
> > vectorized block moving broken and forcing people trying to disable the
> > feature.
> 
> Do you have a testcase?

It's too large and I'm running cvise on it.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #21 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
Created attachment 55421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55421&action=edit
test case broken by draft patch (at -O2 -mavx2 -mtune=haswell)

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #22 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #19)

> Do you have a testcase?

Attached.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #55409|0                           |1
        is obsolete|                            |

--- Comment #23 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 55424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55424&action=edit
An updated patch

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #24 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #23)
> Created attachment 55424 [details]
> An updated patch

Unfortunately Spidermonkey 115 still crashes even with the patch (and -O3
-march=tigerlike -mtune=tigerlake -fno-exceptions).  The problem seems an
unaligned stack slot is assigned for an object of a 512-bit aligned class. 
Then the pointer to the object is passed to another function which stores into
the object with 256-bit vmovdqu but the stack slot is only aligned to 128-bit
in fact.  I'll try to reduce.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[xry111 at gcc dot gnu.org]

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

--- Comment #25 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #24)
> (In reply to H.J. Lu from comment #23)
> > Created attachment 55424 [details]
> > An updated patch
> 
> Unfortunately Spidermonkey 115 still crashes even with the patch (and -O3
> -march=tigerlike -mtune=tigerlake -fno-exceptions).  The problem seems an
> unaligned stack slot is assigned for an object of a 512-bit aligned class. 
> Then the pointer to the object is passed to another function which stores
> into the object with 256-bit vmovdqu but the stack slot is only aligned to
> 128-bit in fact.  I'll try to reduce.

Nope, it seems a bug in mozilla code.

[Bug target/109780] [12/13/14 Regression] csmith: runtime crash with -O2 -march=znver1

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |

--- Comment #26 from Martin Jambor <jamborm at gcc dot gnu.org> ---
Seems like there is nothing to bisect any more, please re-add the keyword is I
am wrong.