[Bug c/108657] New: csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[Bug c/108657] New: csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

            Bug ID: 108657
           Summary: csmith: possible wrong checksum with -O3 and
                    -ftrivial-auto-var-init=zero
           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 54402
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54402&action=edit
C source code

For the attached C code, derived from csmith output, I get:

$ ~/gcc/results/bin/gcc -w bug880.c
$ ./a.out
checksum = F3A34B53
$ ~/gcc/results/bin/gcc -w -O2 bug880.c
$ ./a.out
checksum = F3A34B53
$ ~/gcc/results/bin/gcc -w -O2 -ftrivial-auto-var-init=zero bug880.c
$ ./a.out
checksum = F3A34B53
$ ~/gcc/results/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c
$ ./a.out
checksum = BCC02729
$ ~/gcc/results/bin/gcc -w -O3  bug880.c
$ ./a.out
checksum = F3A34B53
$ 

Also, the possible bug seems to have first occurred sometime before 20230103

$ ~/gcc/results.20230103.asan.ubsan/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$

[Bug c/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

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

After 90 minutes reduction, about 12% of the original is left.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
If I initialize __trans_tmp_13 explictly to 0, the issue goes away ....

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Andrew Pinski from comment #2)
> If I initialize __trans_tmp_13 explictly to 0, the issue goes away ....

$ fgrep trans_tmp_13 bug880.c
           int64_t __trans_tmp_13;
                           (g_452) ^= (__trans_tmp_13);
$ 

This now looks like a bug in csmith.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to David Binderman from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > If I initialize __trans_tmp_13 explictly to 0, the issue goes away ....
> 
> $ fgrep trans_tmp_13 bug880.c
>            int64_t __trans_tmp_13;
>                            (g_452) ^= (__trans_tmp_13);
> $ 
> 
> This now looks like a bug in csmith.

It might be both. I have not looked into the IR differences with respect of
initializing and not initializing it and using/not using
-ftrivial-auto-var-init=zero yet. This was mostly to give a hint to the next
person who looks into this issue to see if they understand why there is a
difference happening.
-ftrivial-auto-var-init=zero should produce the similar results to initializing
that variable to 0 but it is not. There has been some bugs (in GCC) recently in
the area of not executed pathes with uninitialized variables changing the
behavior (incorrectly) so it might be related to one of those ...

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #5 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #0)
> Also, the possible bug seems to have first occurred sometime before 20230103

Also before 20221201:

$ /home/dcb36/gcc/results.20221201/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$ /home/dcb36/gcc/results.20221201/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221130 (experimental) (d0a3d55ae4a2656f) 
$

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #0)
> > Also, the possible bug seems to have first occurred sometime before 20230103
> 
> Also before 20221201:

And before 20221101:

$ /home/dcb36/gcc/results.20221101/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$ /home/dcb36/gcc/results.20221101/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221101 (experimental) (4acc4c2be84d6607) 
$

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #7 from David Binderman <dcb314 at hotmail dot com> ---
I can only go back as far as 20221028, when the git tree was installed.

$ /home/dcb36/gcc/results.20221028/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$ /home/dcb36/gcc/results.20221028/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221028 (experimental) (89999f2358724fa4) 
$ 

I will have a look at how to get at dates before the clone date.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #7)
> I will have a look at how to get at dates before the clone date.

I used snapshots instead. I tried 20221002, and got

$ ./results.20221002/bin/gcc -w -O3 -ftrivial-auto-var-init=zero 
~/gcc/foundBugs/bug880.c && ./a.out
checksum = BCC02729
$ ./results.20221002/bin/gcc -v 2>&1 | fgrep exp
gcc version 13.0.0 20221002 (experimental) (GCC) 
$

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman <dcb314 at hotmail dot com> ---
Same thing, back to 20220807.

[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #10 from David Binderman <dcb314 at hotmail dot com> ---
Bingo ! 

From snapshot 20220703, with g:f3a5e75cb66dc96e, to 20220807, with
g:ef54eb74cab17737, it goes wrong.

Perhaps someone who has the git history would like to bisect this.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|csmith: possible wrong      |[13 Regression] csmith:
                   |checksum with -O3 and       |possible wrong checksum
                   |-ftrivial-auto-var-init=zer |with -O3 and
                   |o                           |-ftrivial-auto-var-init=zer
                   |                            |o
   Target Milestone|---                         |13.0

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[mikpelinux at gmail dot com]

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

--- Comment #11 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Bisected on x86_64-linux-gnu:

dc477ffb4aba21e9cf47de22a4df6f2b23849505 is the first bad commit
commit dc477ffb4aba21e9cf47de22a4df6f2b23849505
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Jul 21 10:13:46 2022 +0200

    tree-optimization/106378 - DSE of LEN_STORE and MASK_STORE

    The following enhances DSE to handle LEN_STORE (optimally) and
    MASK_STORE (conservatively).

            PR tree-optimization/106378
            * tree-ssa-dse.cc (initialize_ao_ref_for_dse): Handle
            LEN_STORE, add mode to initialize a may-def and handle
            MASK_STORE that way.
            (dse_optimize_stmt): Query may-defs.  Handle internal
            functions LEN_STORE and MASK_STORE similar to how
            we handle memory builtins but without byte tracking.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de

--- Comment #12 from David Binderman <dcb314 at hotmail dot com> ---
Perhaps Richard would be willing to offer their best advice.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #13 from David Binderman <dcb314 at hotmail dot com> ---
I tried adding flag 1 to the run of the two binaries. Here is 
the bash history:

 1003  gcc bug880.c
 1004  ./a.out > /tmp/0
 1005  ~/gcc/results/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c -o
b.out
 1006  ./b.out > /tmp/1
 1007  diff /tmp/0 /tmp/1
 1008  ./a.out 1 > /tmp/0
 1009  ./b.out 1 > /tmp/1
 1010  diff /tmp/0 /tmp/1

and got this:

4,12c4,12
< ...checksum after hashing g_78 : 42AE7A83
< ...checksum after hashing g_86 : EA4E5BB
< ...checksum after hashing g_87 : 829B71B1
< ...checksum after hashing g_93 : 454CD723
< ...checksum after hashing g_105 : 589C9AA7
< ...checksum after hashing g_111 : D1C885DD
< ...checksum after hashing g_132 : A790B35F
< ...checksum after hashing g_133 : A9573918
< ...checksum after hashing g_134[i] : 9B3BD0DE
---
> ...checksum after hashing g_78 : 8E047A1D
> ...checksum after hashing g_86 : A0CC742A
> ...checksum after hashing g_87 : 3BE1496
> ...checksum after hashing g_93 : B496D289
> ...checksum after hashing g_105 : F7D808E0
> ...checksum after hashing g_111 : EC796901
> ...checksum after hashing g_132 : BA05A088
> ...checksum after hashing g_133 : 2662148D
> ...checksum after hashing g_134[i] : 3530834A

So someplace in g_78 looks to be the culprit.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[dcb314 at hotmail dot com]

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

--- Comment #14 from David Binderman <dcb314 at hotmail dot com> ---
After five hours of reduction, cvise has:

crc32_tab[256];
unsigned crc32_context = 4294967295;
void crc32_byte(b) {
  crc32_context = crc32_context >> 8 ^ crc32_tab[(crc32_context ^ b) & 255];
}
void transparent_crc(long val, char *vname) {
  crc32_context = crc32_context >> 8 ^ crc32_tab[(crc32_context ^ val) & 255];
  crc32_byte(val >> 8);
  crc32_byte(val >> 16);
  crc32_byte(val >> 24);
  crc32_byte(val >> 32);
  crc32_byte(val >> 40);
  crc32_byte(val >> 48);
  crc32_byte(val >> 56);
  printf("...checksum after hashing %s : %lX\n", vname,
         crc32_context ^ 4294967295);
}
g_21 = -8;
short g_41;
g_78;
static *g_451 = &g_78;
g_452;
func_11___trans_tmp_13;
main_i;
unsigned main_crc;
main_j;
void main() {
  for (; main_i < 256; main_i++) {
    main_crc = main_i;
    main_j = 8;
    for (; main_j; main_j--)
      if (main_crc & 1)
        main_crc = main_crc >> 1 ^ 3988292384;
      else
        main_crc >>= 1;
    crc32_tab[main_i] = main_crc;
  }
  int l_794;
  g_41 = 53935 & g_21;
  g_21 = -18;
  g_78 = 1;
  for (; g_78 >= 0; g_78 -= 1) {
    g_452 = l_794 = 0;
    for (; l_794 <= 3; l_794 += 1) {
      short l_895[1];
      if (g_452)
        break;
      g_452 ^= func_11___trans_tmp_13;
    }
  }
  *g_451 = 8 || 0;
  transparent_crc(g_21, "");
  transparent_crc(g_41, "");
  transparent_crc(2185655400, "");
  transparent_crc(g_78, "g_78");
}

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Slightly cleaned up; aborts with -O3 -ftrivial-auto-var-init=zero,
doesn't abort with -O0, -O3 or -O0 -ftrivial-auto-var-init=zero.

int m[256];
unsigned n = 4294967295;

void
foo (int b)
{
  n = (n >> 8) ^ m[(n ^ b) & 255];
}

void
bar (long x)
{
  n = (n >> 8) ^ m[(n ^ x) & 255];
  foo (x >> 8);
  foo (x >> 16);
  foo (x >> 24);
  foo (x >> 32);
  foo (x >> 40);
  foo (x >> 48);
  foo (x >> 56);
}

int a = -8, c, e, f, g, i;
short b;
static int *d = &c;
unsigned h;

int
main ()
{
  if (__CHAR_BIT__ != 8 || __SIZEOF_SHORT__ != 2 || __SIZEOF_INT__ != 4)
    return 0;
  for (; g < 256; g++)
    {
      h = g;
      for (i = 8; i; i--)
        if (h & 1)
          h = (h >> 1) ^ 3988292384;
        else
          h >>= 1;
      m[g] = h;
    }
  b = 53935 & a;
  a = -18;
  for (c = 1; c >= 0; c -= 1)
    {
      e = 0;
      for (int j = 0; j <= 3; j++)
        {
          short k[1];
          if (e)
            break;
          e ^= f;
        }
    }
  *d = 8 || 0;
  bar (a);
  bar (b);
  bar (2185655400);
  bar (c);
  if (n != 0xbd51857cU)
    __builtin_abort ();
}

The only difference between -O3 and -O3 -ftrivial-auto-var-init=zero in gimple
dump
is the addition of
            k = .DEFERRED_INIT (2, 2, &"k"[0]);
where k is otherwise unused variable.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Slightly more reduced:

int a = -8, c, e, f, g, i;
short b;
static int *d = &c;
int m[256];
unsigned n = ~0U;

void
foo (int b)
{
  n = (n >> 8) ^ m[(n ^ b) & 255];
}

void
bar (long x)
{
  n = (n >> 8) ^ m[(n ^ x) & 255];
  foo (x >> 8);
  foo (x >> 16);
}

int
main ()
{
  if (__CHAR_BIT__ != 8 || __SIZEOF_SHORT__ != 2 || __SIZEOF_INT__ != 4)
    return 0;
  for (g = 0; g < 256; g++)
    m[g] = g;
  b = 53935 & a;
  a = -18;
  for (c = 1; c >= 0; c--)
    {
      e = 0;
      for (int j = 0; j <= 3; j++)
        {
          short k[1];
          if (e)
            break;
          e ^= f;
        }
    }
  *d = 8 || 0;
  bar (a);
  bar (b);
  bar (2185655400);
  bar (c);
  if (n != 0x30)
    __builtin_abort ();
}

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-02-15

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In the assembly, the important difference is that with just -O3 c is assigned 1
before calling the first bar, while -O3 -ftrivial-auto-var-init=zero it is
assigned 0.  This is visible already in optimized dump, which for the latter
stores first c = 1; and then twice c = 0; among the various DEFERRED_INITs.

Even further reduced:
int c, e, f;
static int *d = &c;

__attribute__((noipa)) void
foo (void)
{
  if (c != 1)
    __builtin_abort ();
}

int
main ()
{
  for (c = 1; c >= 0; c--)
    {
      e = 0;
      for (int j = 0; j <= 2; j++)
        {
          short k[1];
          if (e)
            break;
          e ^= f;
        }
    }
  *d = 1;
  foo ();
}

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
fre5 deletes it:
Deleted redundant store c = 1;
Value numbering stmt = foo ();
Setting value number of .MEM_14 to .MEM_14 (changed)
Value numbering stmt = return 0;
RPO iteration over 7 blocks visited 7 blocks in total discovering 7 executable
blocks iterating 1.0 times, a block was visited max. 1 times
RPO tracked 20 values available at 1 locations and 20 lattice elements
Removing dead stmt c = 1;

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With the deferred stuff (why don't we DCE it for variables which are otherwise
not used?), all looks fine until fre5.
In fre4 we have
  k ={v} {CLOBBER(eol)};
  c = -1;
  c = 1;
  foo ();
  return 0;
at the end which is reasonable, the outer loop iterates c = 1, c = 0 and c = -1
and then c = 1 is stored, dse4 optimizes it to:
  k ={v} {CLOBBER(eol)};
  c = 1;
  foo ();
  return 0;
in split-path, we have in bb2
  c = 1;
then in one of the conditionalized bbs
  c = 0;
and finally still
  <bb 8> [local count: 38651690]:
  k ={v} {CLOBBER(eol)};
  c = 1;
  foo ();
  return 0;
at the end, but fre5 keeps those c = 1; and c = 0; early stores and drops the
last one.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Looking at the r13-1778 change, perhaps it wasn't intended that it changed
behavior for all internal functions that return non-SSA_NAME result.
--- gcc/tree-ssa-dse.cc.jj      2023-01-11 10:29:08.651161134 +0100
+++ gcc/tree-ssa-dse.cc 2023-02-15 20:03:33.647684713 +0100
@@ -177,7 +177,7 @@ initialize_ao_ref_for_dse (gimple *stmt,
        default:;
        }
     }
-  else if (tree lhs = gimple_get_lhs (stmt))
+  if (tree lhs = gimple_get_lhs (stmt))
     {
       if (TREE_CODE (lhs) != SSA_NAME)
        {
fixes this.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 54472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54472&action=edit
gcc13-pr108657.patch

Untested fix.  This one fixes the DSE bug which caused the .DEFERRED_INIT calls
not to be DSEd.  Though, I wonder if we still don't have a bug in FRE...

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
           Keywords|needs-reduction             |

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:866555b170016c49beb869a78cbecdeb07c63135

commit r13-6083-g866555b170016c49beb869a78cbecdeb07c63135
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]

    The r13-1778 PR106378 tree-ssa-dse change didn't just add special support
    for IFN_LEN_STORE and IFN_MASK_STORE internal function calls as I believe
    was intended, but given that the function was
    if (is builtin) { ... }
    else if (lhs present and non-SSA_NAME) { ... }
    return false;
    and it added a new
    else if (is internal builtin) { ... }
    in between the two, the last if used to be done before on all stmts
    with non-SSA_NAME lhs except for calls to builtin functions, but newly
    isn't done also for calls to internal functions.  In the testcase
    the important internal function is .DEFERRED_INIT, which often has
    non-SSA_NAME lhs, and the change resulted in them no longer being DSEd,
    so a block with nothing in it left but var = .DEFERRED_INIT () and
    var = {CLOBBER} was unrolled several times.

    The following patch does the lhs handling for all stmts with non-SSA_NAME
lhs
    unless initialize_ao_ref_for_dse handled those specially already and
    returned (which is the case for various mem* builtins which don't have
    such lhs, for some cases of calloc which again is fine,and since r13-1778
    also for IFN_LEN_STORE call and some IFN_MASK_STORE calls.
    As IFN_MASK_STORE doesn't have a lhs, the break for the !may_def_ok case
    doesn't seem to change anything, and because we've handled internal fns
    that way in the past, I think it is the right thing to do that again.
    That said, if it is inappropriate for some new ifn, I guess it could
    be added to the switch and just return false; for it instead of break;.

    2023-02-16  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/108657
            * tree-ssa-dse.cc (initialize_ao_ref_for_dse): If lhs of stmt
            exists and is not a SSA_NAME, call ao_ref_init even if the stmt
            is a call to internal or builtin function.

            * gcc.dg/pr108657.c: New test.

[Bug middle-end/108657] [13 Regression] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed I guess (and the FRE issue as well).