[Bug c/109093] New: csmith: a February runtime bug ?

[Bug c/109093] New: csmith: a February runtime bug ?

[dcb314 at hotmail dot com]

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

            Bug ID: 109093
           Summary: csmith: a February 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 54636
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54636&action=edit
C source code

For the attached C code, compiled by recent gcc and flags -O3 -march=znver1 
-fno-strict-aliasing -ftrivial-auto-var-init=zero, does this:

/home/dcb36/gcc/results.20230215.asan.ubsan/bin/gcc
checksum = 95F158F5
/home/dcb36/gcc/results.20230216/bin/gcc
checksum = 95F158F5
/home/dcb36/gcc/results.20230217.asan.ubsan/bin/gcc
Segmentation fault (core dumped)
/home/dcb36/gcc/results.20230218.asan.ubsan/bin/gcc
Segmentation fault (core dumped)

20230216 has git hash g:7478278f88ba1753 and 20230217 has g:f978585c29396911.
This is a range of 30 commits.

I will have a go at a git bisect. This is bug #895 for me.

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
Current git range is g:7478278f88ba1753 .. g:fea34ee491104f32

This is 7 commits. 6 of them seem to be libstdc++ and then there is
this one:

commit 866555b170016c49beb869a78cbecdeb07c63135
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 16 15:35:05 2023 +0100

    tree-ssa-dse: Fix up handling of lhs of internal calls [PR108657]

This is the current hot candidate.

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
As expected:

$ git bisect bad 866555b170016c49
866555b170016c49beb869a78cbecdeb07c63135 is the first bad commit
commit 866555b170016c49beb869a78cbecdeb07c63135
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Feb 16 15:35:05 2023 +0100

    tree-ssa-dse: Fix up handling of lhs of internal calls [PR108657]

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 54638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54638&action=edit
C source code

This C code seems to fail in the same way. Possible duplicate.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
            Summary|csmith: a February runtime  |[13 regression] csmith: a
                   |bug ?                       |February runtime bug ?
           Keywords|                            |needs-reduction

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 54639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54639&action=edit
C source code

A third example that fails at the same git hash.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl.tools at gmail dot com

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
My patch just caused far more .DEFERRED_INITs to be optimized away for dead
variables (though, as can be seen on #c0 apparently not all).
What I see on the #c0 testcase looks like a x86 backend bug to me.
In func_2.constprop.0.isra.0 there is in optimized dump:
  uint64_t * * * * const * l_2254[6];
variable and the IL mentions it just in
  l_2254 = .DEFERRED_INIT (48, 2, &"l_2254"[0]);
and
  l_2254 ={v} {CLOBBER(eol)};
(the latter in 2 spots) statements.  Why the .DEFERRED_INIT hasn't been DSEd is
certainly a question.
Anyway, l_2254 has 128-bit alignment (supposedly due to ix86_local_alignment
and psABI requirements).
Expansion expands that .DEFERRED_INIT into:
(insn 23 22 24 5 (parallel [
            (set (reg:DI 162)
                (plus:DI (reg/f:DI 19 frame)
                    (const_int -48 [0xffffffffffffffd0])))
            (clobber (reg:CC 17 flags))
        ]) "runData/keep/in.16651.c":199:34 247 {*adddi_1}
     (nil))
(insn 24 23 25 5 (set (reg:V32QI 163)
        (const_vector:V32QI [
                (const_int 0 [0]) repeated x32
            ])) "runData/keep/in.16651.c":199:34 1823 {movv32qi_internal}
     (nil))
(insn 25 24 26 5 (set (mem/c:V16QI (reg:DI 162) [0 MEM <char[1:48]> [(void
*)_157]+0 S16 A128])
        (vec_select:V16QI (reg:V32QI 163)
            (parallel [
                    (const_int 0 [0])
                    (const_int 1 [0x1])
                    (const_int 2 [0x2])
                    (const_int 3 [0x3])
                    (const_int 4 [0x4])
                    (const_int 5 [0x5])
                    (const_int 6 [0x6])
                    (const_int 7 [0x7])
                    (const_int 8 [0x8])
                    (const_int 9 [0x9])
                    (const_int 10 [0xa])
                    (const_int 11 [0xb])
                    (const_int 12 [0xc])
                    (const_int 13 [0xd])
                    (const_int 14 [0xe])
                    (const_int 15 [0xf])
                ]))) "runData/keep/in.16651.c":199:34 4383
{vec_extract_lo_v32qi}
     (nil))
(insn 26 25 27 5 (set (mem/c:V16QI (plus:DI (reg:DI 162)
                (const_int 16 [0x10])) [0 MEM <char[1:48]> [(void *)_157]+16
S16 A128])
        (vec_select:V16QI (reg:V32QI 163)
            (parallel [
                    (const_int 16 [0x10])
                    (const_int 17 [0x11])
                    (const_int 18 [0x12])
                    (const_int 19 [0x13])
                    (const_int 20 [0x14])
                    (const_int 21 [0x15])
                    (const_int 22 [0x16])
                    (const_int 23 [0x17])
                    (const_int 24 [0x18])
                    (const_int 25 [0x19])
                    (const_int 26 [0x1a])
                    (const_int 27 [0x1b])
                    (const_int 28 [0x1c])
                    (const_int 29 [0x1d])
                    (const_int 30 [0x1e])
                    (const_int 31 [0x1f])
                ]))) "runData/keep/in.16651.c":199:34 4384
{vec_extract_hi_v32qi}
     (nil))
(insn 27 26 28 5 (set (mem/c:V16QI (plus:DI (reg:DI 162)
                (const_int 32 [0x20])) [0 MEM <char[1:48]> [(void *)_157]+32
S16 A128])
        (subreg:V16QI (reg:V32QI 163) 0)) "runData/keep/in.16651.c":199:34 1824
{movv16qi_internal}
     (nil))
cmpelim dump still has:
(insn 279 6 25 4 (set (reg/f:DI 38 r10 [215])
        (plus:DI (reg/f:DI 7 sp)
            (const_int -48 [0xffffffffffffffd0]))) 241 {*leadi}
     (expr_list:REG_EQUIV (plus:DI (reg/f:DI 19 frame)
            (const_int -48 [0xffffffffffffffd0]))
        (nil)))
(insn 25 279 26 4 (set (reg:V16QI 21 xmm1 [orig:218 MEM <char[1:48]> [(void
*)_157] ] [218])
        (const_vector:V16QI [
                (const_int 0 [0]) repeated x16
            ])) "runData/keep/in.16651.c":199:34 1824 {movv16qi_internal}
     (expr_list:REG_EQUIV (const_vector:V16QI [
                (const_int 0 [0]) repeated x16
            ])
        (nil)))
(insn 26 25 34 4 (set (reg:V16QI 20 xmm0 [orig:219 MEM <char[1:48]> [(void
*)_157]+16 ] [219])
        (reg:V16QI 21 xmm1)) "runData/keep/in.16651.c":199:34 1824
{movv16qi_internal}
     (expr_list:REG_EQUIV (const_vector:V16QI [
                (const_int 0 [0]) repeated x16
            ])
        (nil)))
before the loop and
(insn 289 22 290 5 (set (mem/c:V16QI (reg/f:DI 38 r10 [215]) [0 MEM
<char[1:48]> [(void *)_157]+0 S16 A128])
        (reg:V16QI 21 xmm1 [orig:218 MEM <char[1:48]> [(void *)_157] ] [218]))
"runData/keep/in.16651.c":199:34 1824 {movv16qi_internal}
     (nil))
(insn 290 289 291 5 (set (mem/c:V16QI (plus:DI (reg/f:DI 38 r10 [215])
                (const_int 16 [0x10])) [0 MEM <char[1:48]> [(void *)_157]+16
S16 A128])
        (reg:V16QI 20 xmm0 [orig:219 MEM <char[1:48]> [(void *)_157]+16 ]
[219])) "runData/keep/in.16651.c":199:34 1824 {movv16qi_internal}
     (nil))
(insn 291 290 29 5 (set (mem/c:V16QI (plus:DI (reg/f:DI 38 r10 [215])
                (const_int 32 [0x20])) [0 MEM <char[1:48]> [(void *)_157]+32
S16 A128])
        (reg:V16QI 20 xmm0 [orig:219 MEM <char[1:48]> [(void *)_157]+16 ]
[219])) "runData/keep/in.16651.c":199:34 1824 {movv16qi_internal}
     (nil))
in the loop. stack_alignment_needed is 128, but then pro_and_epilogue decides
to do:
(insn/f 337 315 338 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
        (reg/f:DI 6 bp)) "runData/keep/in.16651.c":157:16 -1
     (nil))
(insn/f 338 337 339 2 (set (reg/f:DI 6 bp)
        (reg/f:DI 7 sp)) "runData/keep/in.16651.c":157:16 -1
     (nil))
(insn/f 339 338 340 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
        (reg:DI 41 r13)) "runData/keep/in.16651.c":157:16 -1
     (nil))
(insn/f 340 339 341 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
        (reg:DI 40 r12)) "runData/keep/in.16651.c":157:16 -1
     (nil))
(insn/f 341 340 342 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0  S8 A8])
        (reg:DI 3 bx)) "runData/keep/in.16651.c":157:16 -1
     (nil))
(insn 342 341 343 2 (set (mem/v:BLK (scratch:DI) [0  A8])
        (unspec:BLK [
                (mem/v:BLK (scratch:DI) [0  A8])
            ] UNSPEC_MEMORY_BLOCKAGE)) "runData/keep/in.16651.c":157:16 -1
     (nil))
...
(insn 279 6 25 3 (set (reg/f:DI 38 r10 [215])
        (plus:DI (reg/f:DI 7 sp)
            (const_int -48 [0xffffffffffffffd0]))) 241 {*leadi}
     (expr_list:REG_EQUIV (plus:DI (reg/f:DI 19 frame)
            (const_int -48 [0xffffffffffffffd0]))
        (nil)))
which ends up:
        pushq   %rbp
.LCFI5:
        movq    %rsp, %rbp
.LCFI6:
        pushq   %r13
        pushq   %r12
        pushq   %rbx
...
        leaq    -48(%rsp), %r10
...
        vmovdqa %xmm1, (%r10)
        vmovdqa %xmm0, 16(%r10)
        movl    $8, %esi
        vmovdqa %xmm0, 32(%r10)
But, this result in unaligned stores, because %rsp on entry to x86_64 functions
should be (%rsp & 15) == 8, such that %rbp is 16-byte aligned,
and then it does 3 pushes (24 bytes) and allocates l_2254 48 bytes below that,
so at %rbp - 72 bytes, so all the 3 vector stores are unaligned
((%r10 & 15) == 8).

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-03-13
             Status|UNCONFIRMED                 |NEW

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
#c3 looks very similarly, though have just looked at assembly:
        pushq   %rbp
.LCFI0:
        movl    $36, %r11d
        movl    $7, %eax
        vpxor   %xmm0, %xmm0, %xmm0
        movq    %rsp, %rbp
.LCFI1:
        pushq   %r15
        pushq   %r14
        pushq   %r13
        pushq   %r12
.LCFI2:
        movl    $127, %r13d
        pushq   %rbx
.LCFI3:
        leaq    -48(%rsp), %rsi
...
.L5:
        vmovdqa %xmm0, (%rsi)
so again, %rbp after movq %rsp, %rbp is correctly 16-byte aligned, then 5
registers are pushed, so (%rsp & 15) == 8, %rsi is set to %rsp - 48 and an
aligned store to that spot
segfaults because (%rsi & 15) == 8.

And similarly #c4:
        pushq   %rbp
.LCFI0:
        movabsq $434041037028460038, %rax
        movq    %rsp, %rbp
.LCFI1:
        pushq   %rbx
.LCFI2:
        movq    %rax, -41(%rsp)
        movb    $6, -33(%rsp)
        cmpl    $-6, (%rdi)
        jne     .L84
        movl    $2, %r8d
        leaq    -32(%rsp), %rcx
...
        vmovdqa %xmm1, (%rcx)
        vmovdqa %xmm0, 16(%rcx)

H.J., could you please have a look?  Thanks.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase (unfortunately reduced into a form which is x86_64-linux
specific unless I want success to be an endless loop)
with -O2 -mavx -mtune=znver1 -ftrivial-auto-var-init=zero:

int a, b, c, d, e, f, g, h, i, j, k;
int *m;
int **l = &m;

static void
bar (void)
{
l:
  if (j)
    for (;;)
      ;
  short q[3];
  if (g)
    goto l;
  for (; k; k -= 1)
    {
      int *r = &g;
      *r = i;
      for (f = 0; f <= 6; f += 1)
        {
          if (*l)
            {
              d += 1;
              for (; d;)
                ;
            }
          if (e)
            break;
        }
    }
}

__attribute__((noipa)) void
foo (int *x)
{
  int n;
  long o = 1;
  if (*x)
    {
      bar ();
      ++o;
      n = a / o;
    }
  h |= n;
  for (;;)
    {
      int *p[4];
      *l = x;
      for (b = 0; b <= 2; b += 1)
        if (c)
          {
            asm ("pushq %rbp; xorl %edi, %edi; movq %rsp, %rbp; andq $-16,
%rsp; call exit");
            break;
          }
        else
          *m = 0;
    }
}

int
main ()
{
  int x = 1;
  c = 1;
  foo (&x);
  return 0;
}

Started (or perhaps no longer latent) since
r13-4839-geef81eefcdc2a58111e50eb21.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> Started (or perhaps no longer latent) since
> r13-4839-geef81eefcdc2a58111e50eb21.

Most likely made no longer latent due to:
(X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3.
(X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3.
Just as I mentioned in PR 109087.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps better reduction which doesn't need inline asm.  It contains a couple
of unused variables and two spots with uninitialized vars, but those should be
both in a block of code never executed at runtime.  And the various ptr vs.
integral casts are also needed but I think they shouldn't do much harm (it is
true in one spot it creates a pointer from int, but only stores it somewhere
and doesn't actually use later).

/* PR target/109093 */
/* { dg-do run { target avx_runtime } } */
/* { dg-options "-O3 -mavx -mtune=znver1 -fno-strict-aliasing
-ftrivial-auto-var-init=zero" } */

int a, b = 1, c, d, e, f, g, h, i, j, k, l, m;
int *n = &d, *o = &i, *p = &h;
static int q;
int *f2;
int **r = &f2, **s = &o;
char t;
int u[1];
int ***v;

static void
foo (int x)
{
  int *w[7];
  int y = y, i;
  const int z[32] = { };
  int aa = (__PTRDIFF_TYPE__) z;
  for (i = 0; i < 7; i++)
    w[i] = u;
lab:
  *r = (int *) (__PTRDIFF_TYPE__) x;
  if (k || p == 0)
    {
      int ab[1];
      for (; g; g++)
        {
          int **ac[] = { w };
        }
      short ad[3];
      if (j)
        goto lab;
      for (; y; y -= 1)
        {
          int *ae;
          *ae = l;
          for (; t; t += 1)
            if (**r)
              return;
          for (; q; q += f)
            ;
        }
    }
}

static void
bar (int *x)
{
  long w[] = { 1, 1, 4073709551607, 1, 1 };
  if (*x + 6)
    {
      (void) ((**s |= a) > (__PTRDIFF_TYPE__) w);
      foo (d);
    }
  for (e = 0; e <= 2; e += 1)
    {
      int *y[4];
      r = (int **) x;
      for (m = 0; m <= 2; m += 1)
        for (b = 0; b <= 2; b += 1)
          if (c)
            {
              q = 0;
              ***v = (__PTRDIFF_TYPE__) r;
            }
    }
}

int
main ()
{
  if (b)
    bar (n);
}

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[hjl.tools at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> ---
We have

static bool
ix86_can_eliminate (const int from, const int to)
{
  if (stack_realign_fp)
    return ((from == ARG_POINTER_REGNUM
             && to == HARD_FRAME_POINTER_REGNUM)
            || (from == FRAME_POINTER_REGNUM
                && to == STACK_POINTER_REGNUM));
  else  
    return to == STACK_POINTER_REGNUM ? !frame_pointer_needed : true; 
}

Before IRA, stack_realign_fp is set to true by AVX piecewise move and store.
LRA replaces frame pointer with stack pointer:

insn 259 261 297 4 (set (reg/f:DI 2 cx [144])
        (plus:DI (reg/f:DI 7 sp)
            (const_int -32 [0xffffffffffffffe0]))) 241 {*leadi}
     (expr_list:REG_EQUAL (plus:DI (reg/f:DI 19 frame)
            (const_int -32 [0xffffffffffffffe0]))
        (nil)))

In ix86_finalize_stack_frame_flags, stack_realign_fp is set to false. Since
the stack realignment skipped, local variable is no longer properly aligned.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-reduction             |

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But we don't really need to dynamically realign anything in this case as there
are is nothing on the stack that needs 32-byte alignment, but there is
something that needs 16-byte alignment and so the frame size needs to be a
multiple of 16 like it is if there would be a call.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
ix86_find_max_used_stack_alignment fails to detect that

(insn 281 152 282 34 (set (mem/c:V16QI (reg/f:DI 2 cx [144]) [0 MEM
<char[1:32]> [(void *)_109]+0 S16 A128])
        (reg:V16QI 21 xmm1 [orig:156 MEM <char[1:32]> [(void *)_109] ] [156]))
"x.c":53:12 1824 {movv16qi_internal}
     (nil))

requires 16-byte aligned stack.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #12)
> ix86_find_max_used_stack_alignment fails to detect that
> 
> (insn 281 152 282 34 (set (mem/c:V16QI (reg/f:DI 2 cx [144]) [0 MEM
> <char[1:32]> [(void *)_109]+0 S16 A128])
>         (reg:V16QI 21 xmm1 [orig:156 MEM <char[1:32]> [(void *)_109] ]
> [156])) "x.c":53:12 1824 {movv16qi_internal}
>      (nil))
> 
> requires 16-byte aligned stack.

I guess it raises 3 questions:
1) why hasn't combine or cse etc. merged the
(insn 153 152 154 38 (parallel [
            (set (reg:DI 135)
                (plus:DI (reg/f:DI 19 frame)
                    (const_int -32 [0xffffffffffffffe0])))
            (clobber (reg:CC 17 flags))
        ]) "pr109093-8.c":59:12 247 {*adddi_1}
     (nil))
into the stores?  Seems cprop2 hoists it before the loop instead, but that
doesn't seem to be a win when it is something that can refer to the stack
directly
2) ix86_find_max_used_stack_alignment only goes after MEMs which mention
sp/frame, so isn't able to discover the cases where lea sp + offset is stored
into some register and later used in some MEM; shall it take into account also
MEMs which have local automatic vars in MEM_EXPR regardless of whether they
requires_stack_frame_p or not, and regardless of whether they mention sp/frame
or not?  Or say use cselib to see through VALUEs (though I'm afraid even that
wouldn't catch reliably everything).

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I assume if calls are present this is no longer a problem (so say hiding
accesses from
taking of address through some function call or doing accesses in the call is
safe).
But, one could e.g. use inline asm to hide it, have __m128 x; __m128 *p = &x;
asm ("" : "+r" (p)); *p = 0; etc.?

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[hjl.tools at gmail dot com]

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

--- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> ---
The crash went away after r13-6661-gbd6e566e9dc543 which removed variables only
used with .DEFERRED_INIT.  If variables are used, they will be captured by
ix86_find_max_used_stack_alignment.  Is there a testcase without unused
variables?

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I don't see where ix86_find_max_used_stack_alignment would walk over local vars
and for TREE_USED ones take their alignment into account.  Is that done
somewhere else?
If yes, it would be nice to know where and in that case perhaps Richi's commit
is a real fix.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[hjl.tools at gmail dot com]

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

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

Change ix86_find_max_used_stack_alignment to find alignments of all stack slot
accesses.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd like to understand what is the difference between those .DEFERRED_INITs on
unused vars and normal vars.
If I try
typedef int V __attribute__((vector_size (16)));

__attribute__((noipa)) void
foo ()
{
  V v;
  V *p = &v;
  asm ("" : "+r" (p));
  *p = (V) {};
  asm volatile ("" : : : "r12", "r13", "r14");
}

__attribute__((noipa)) void
bar ()
{
  V v;
  V *p = &v;
  asm ("" : "+r" (p));
  *p = (V) {};
  asm volatile ("" : : : "r12", "r13");
}

int
main ()
{
  foo ();
  bar ();
}

with either -O2 -mavx or -O2 -mavx -fno-omit-frame-pointer, then everything is
properly aligned.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[hjl.tools at gmail dot com]

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

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
.DEFERRED_INIT has

insn 259 261 297 4 (set (reg/f:DI 144) 
        (plus:DI (reg/f:DI 19 frame)
            (const_int -32 [0xffffffffffffffe0]))) 241 {*leadi}
     (expr_list:REG_EQUAL (plus:DI (reg/f:DI 19 frame)
            (const_int -32 [0xffffffffffffffe0]))
        (nil)))

vs explicit __builtin_memset

insn 264 149 153 34 (set (reg/f:DI 144) 
        (plus:DI (reg/f:DI 19 frame)
            (const_int -32 [0xffffffffffffffe0]))) 241 {*leadi}
     (expr_list:REG_EQUIV (plus:DI (reg/f:DI 19 frame)
            (const_int -32 [0xffffffffffffffe0]))
        (nil)))

LRA can eliminate (reg/f:DI 144) with REG_EQUIV, but not with REG_EQUAL.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #19)
> .DEFERRED_INIT has
> 
> insn 259 261 297 4 (set (reg/f:DI 144) 
>         (plus:DI (reg/f:DI 19 frame)
>             (const_int -32 [0xffffffffffffffe0]))) 241 {*leadi}
>      (expr_list:REG_EQUAL (plus:DI (reg/f:DI 19 frame)
>             (const_int -32 [0xffffffffffffffe0]))
>         (nil)))
> 
> vs explicit __builtin_memset
> 
> insn 264 149 153 34 (set (reg/f:DI 144) 
>         (plus:DI (reg/f:DI 19 frame)
>             (const_int -32 [0xffffffffffffffe0]))) 241 {*leadi}
>      (expr_list:REG_EQUIV (plus:DI (reg/f:DI 19 frame)
>             (const_int -32 [0xffffffffffffffe0]))
>         (nil)))
> 
> LRA can eliminate (reg/f:DI 144) with REG_EQUIV, but not with REG_EQUAL.

Neither .DEFERRED_INIT nor explicit zero initialization fills those at all, try
-O2 -ftrivial-auto-var-init=zero:
void foo (char *);

void
bar (void)
{
  char a[48];
  char b[48] = {};
  foo (a);
  foo (b);
}

REG_EQUAL (in both cases) is added during cse1.

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu <hjl.tools at gmail dot com> ---
REG_EQUIV is added by IRA:

          if (DF_REG_DEF_COUNT (regno) == 1
              && note
              && !rtx_varies_p (XEXP (note, 0), 0)
              && (!may_trap_or_fault_p (XEXP (note, 0))
                  || def_dominates_uses (regno))) 
            {
              rtx note_value = XEXP (note, 0);
              remove_note (insn, note);
              set_unique_reg_note (insn, REG_EQUIV, note_value);
            }

[Bug target/109093] [13 regression] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

--- Comment #22 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/109093] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3
            Summary|[13 regression] csmith: a   |csmith: a February runtime
                   |February runtime bug ?      |bug ?

[Bug target/109093] csmith: a February runtime bug ?

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #24 from David Binderman <dcb314 at hotmail dot com> ---
Attached C code does this:

$ for i in ../results.202302??/bin/gcc; do echo $i; $i -w -O2 -march=znver1
-ftrivial-auto-var-init=zero bug918.c; ./a.out; done
../results.20230205/bin/gcc
checksum = 82D25348
../results.20230212/bin/gcc
checksum = 82D25348
../results.20230219/bin/gcc
Segmentation fault (core dumped)
$

[Bug target/109093] csmith: a February runtime bug ?

[dcb314 at hotmail dot com]

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

--- Comment #25 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 55030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55030&action=edit
C source code

[Bug target/109093] csmith: a February runtime bug ?

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug target/109093] csmith: a February runtime bug ?

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 109087 has been marked as a duplicate of this bug. ***

[Bug target/109093] csmith: a February runtime bug ?

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.