[Bug c/102285] New: New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[Bug c/102285] New: New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[dcb314 at hotmail dot com]

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

            Bug ID: 102285
           Summary: New flag -ftrivial-auto-var-init=zero causes many
                    crashes in the testsuite
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For the C source code under gcc/trunk/gcc/testsuite, I did:

$ find . -name \*.c -print | sort > file.c.list
$ head file.c.list
./ada/acats/tests/cd/cd300051.c
./ada/acats/tests/cxb/cxb30040.c
./ada/acats/tests/cxb/cxb30060.c
./ada/acats/tests/cxb/cxb30130.c
./ada/acats/tests/cxb/cxb30131.c
./c-c++-common/addrtmp.c
./c-c++-common/array-1.c
./c-c++-common/array-5.c
./c-c++-common/array-6.c
./c-c++-common/array-init.c
$ wc -l file.c.list
42647 file.c.list
$

So I did a bit of light testing:

$ for i in `cat file.c.list`; do echo $i; /home/dcb/gcc/results/bin/gcc -c -g
-O2 -Wall -ftrivial-auto-var-init=zero  $i; done > 11.out 2>&1 
$

Normally, this kind of for loop would produce a small number of crashes.
Instead, I get 25 and it's only done about 25% of all the C source code files.

$ grep -c "\.c$" 11.out 
9184
$ 

The compiler is built with checking enabled.

Here are the first few:

$ fgrep "internal compiler error:" 11.out | head
./c-c++-common/dfp/func-vararg-size0.c:16:5: internal compiler error:
Segmentation fault
./c-c++-common/dfp/struct-layout-1.c:51:5: internal compiler error:
Segmentation fault
./c-c++-common/gomp/reduction-1.c:8:1: internal compiler error: Segmentation
fault
./c-c++-common/gomp/udr-1.c:11:1: internal compiler error: Segmentation fault
./c-c++-common/torture/pr46137.c:13:1: internal compiler error: Segmentation
fault
./c-c++-common/ubsan/bounds-14.c:6:1: internal compiler error: Segmentation
fault
./c-c++-common/Warray-bounds-10.c:63:6: internal compiler error: Segmentation
fault
./c-c++-common/Warray-bounds-9.c:12:12: internal compiler error: Segmentation
fault
./c-c++-common/Wsizeof-pointer-memaccess1.c:71:1: internal compiler error:
Segmentation fault
./c-c++-common/Wsizeof-pointer-memaccess2.c:176:1: internal compiler error:
Segmentation fault
$ 

The -ftrivial... flag although a good idea, doesn't look ready for
prime time yet. I suggest it is removed and the original code reworked
until it doesn't cause any "internal compiler error:" for the C testsuite.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
(In reply to David Binderman from comment #0)
> For the C source code under gcc/trunk/gcc/testsuite, I did:
>
> ./c-c++-common/dfp/func-vararg-size0.c:16:5: internal compiler error:
> Segmentation fault


I just tried:
[opc@qinzhao-ol8u3-x86 gcc]$ cat t
/home/opc/Work/GCC/build/gcc/xgcc -B/home/opc/Work/GCC/build/gcc/
/home/opc/Work/GCC/latest-gcc/gcc/testsuite/c-c++-common/dfp/func-vararg-size0.c
-g -ftrivial-auto-var-init=zero -fdump-tree-gimple -O2
[opc@qinzhao-ol8u3-x86 gcc]$ sh t

i.e, I didn't get the segmentation fault.

could you list the full command line for the above testing case?

Did you check with the latest upstream GCC? there are two bugs that had been
fixed by Richard B last night.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[qinzhao at gcc dot gnu.org]

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
I checked all the listed testing cases with the latest GCC + -g
-ftrivial-auto-var-init=pattern  -O2

all passed without issue.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I wonder if most of these were fixed by r12-3447-g79f488de3036a

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[qing.zhao at oracle dot com]

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

--- Comment #4 from Qing Zhao <qing.zhao at oracle dot com> ---
> On Sep 10, 2021, at 5:34 PM, pinskia at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
> 
> --- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> I wonder if most of these were fixed by r12-3447-g79f488de3036a

There are two patches by Richard Biener last night to fix two bugs:

commit 79f488de3036a4a4be08df2a782e6eb02419db19
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Sep 10 12:28:09 2021 +0200

    middle-end/102273 - avoid ICE with auto-init and nested functions

    This refactors expansion to consider non-decl LHS.  I suspect
    the is_val argument is not needed.

commit 1dae802b685937b1dc52e49d0641c75f3186ba14
Author: Richard Biener <rguenther@suse.de>
Date:   Fri Sep 10 10:17:24 2021 +0200

    middle-end/102269 - avoid auto-init of empty types

    This avoids initializing empty types for which we'll eventually
    leave a .DEFERRED_INIT call without a LHS.

I checked the failed testing cases listed by David, many of them have empty
types.

So, I guess that the above two patches might already fix these failures.


> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[qinzhao at gcc dot gnu.org]

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

--- Comment #5 from qinzhao at gcc dot gnu.org ---
with the latest GCC, for all the 42647 c files under gcc/testsuite, with -c -g
-O2 -Wall -ftrivial-auto-var-init=zero, there is only one failure:
 /home/opc/Install/latest/bin/gcc -c -g -ftrivial-auto-var-init=zero -O2 -Wall
./gcc.dg/graphite/pr82421.c

during RTL pass: expand
./gcc.dg/graphite/pr82421.c: In function ‘qy’:
./gcc.dg/graphite/pr82421.c:10:7: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:8432
   10 |   int fb[tw];
      |       ^~
0x6b3494 expand_expr_addr_expr_1
        ../../latest-gcc/gcc/expr.c:8432
0xaecd9d expand_expr_addr_expr
        ../../latest-gcc/gcc/expr.c:8545
0xaecd9d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../latest-gcc/gcc/expr.c:11761
0xaeac65 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
        ../../latest-gcc/gcc/expr.c:8733
0xaeac65 expand_expr
        ../../latest-gcc/gcc/expr.h:301
0xaeac65 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        ../../latest-gcc/gcc/expr.c:9053
0xaeb732 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../latest-gcc/gcc/expr.c:11818
0x991030 expand_expr
        ../../latest-gcc/gcc/expr.h:301
0x991030 get_memory_rtx
        ../../latest-gcc/gcc/builtins.c:1369
0x9989f5 expand_builtin_memset_args
        ../../latest-gcc/gcc/builtins.c:4101
0x9c4a67 expand_call_stmt
        ../../latest-gcc/gcc/cfgexpand.c:2749
0x9c4a67 expand_gimple_stmt_1
        ../../latest-gcc/gcc/cfgexpand.c:3876
0x9c4a67 expand_gimple_stmt
        ../../latest-gcc/gcc/cfgexpand.c:4040
0x9cac8b expand_gimple_basic_block
        ../../latest-gcc/gcc/cfgexpand.c:6082
0x9cc98f execute
        ../../latest-gcc/gcc/cfgexpand.c:6808
Please submit a full bug report,

delete -ftrivial-auto-var-init=zero, the failure is gone.

I will study this one to fix it.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to qinzhao from comment #5)
> with the latest GCC, for all the 42647 c files under gcc/testsuite, with -c
> -g -O2 -Wall -ftrivial-auto-var-init=zero, there is only one failure:
>  /home/opc/Install/latest/bin/gcc -c -g -ftrivial-auto-var-init=zero -O2
> -Wall ./gcc.dg/graphite/pr82421.c

> delete -ftrivial-auto-var-init=zero, the failure is gone.
> 
> I will study this one to fix it.

Good news. I'll test with -O3 -march=native, and if it passes then the C side 
of things looks good enough for prime time.

I will then test C++ and Fortran in a similar way, and if they pass too,
then the new flag looks IMHO ready for other compiler users.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, you can do

make check RUNTESTFLAGS="--target_board=unix/-ftrivial-auto-var-init=zero"

to have dejagnu automagically add the flag to all tests (doesn't work for Ada
ACATS)

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |qinzhao at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-09-13
             Status|UNCONFIRMED                 |ASSIGNED

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
the ICE is triggered by the following IR:

MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);

which is transformed from the original IR:

(*fb.1_9) = .DEFERRED_INIT (16, 2, 1);

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
the direct cause of the ICE is because:

MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);

in the above, the fb.3 is in REG instead MEM:

8451              gcc_assert (MEM_P (result));
(gdb) call debug_tree(exp)
 <var_decl 0x7fffe94605a0 fb.3
    type <array_type 0x7fffe9463498
        type <integer_type 0x7fffe9463348 public unsigned QI
            size <integer_cst 0x7fffe92f8e28 constant 8>
            unit-size <integer_cst 0x7fffe92f8e40 constant 1>
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9463348 precision:8 min <integer_cst 0x7fffe94427b0 0> max <integer_cst
0x7fffe9317420 255>>
        TI
        size <integer_cst 0x7fffe92f8d80 constant 128>
        unit-size <integer_cst 0x7fffe92f8d98 constant 16>
        align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9463498
        domain <integer_type 0x7fffe94633f0 type <integer_type 0x7fffe9313000
sizetype>
            DI
            size <integer_cst 0x7fffe92f8d38 constant 64>
            unit-size <integer_cst 0x7fffe92f8d50 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe94633f0 precision:64 min <integer_cst 0x7fffe92f8d68 0> max <integer_cst
0x7fffe94427e0 15>>
        pointer_to_this <pointer_type 0x7fffe9463540>>
    used ignored TI pr82421.c:10:7 size <integer_cst 0x7fffe92f8d80 128>
unit-size <integer_cst 0x7fffe92f8d98 16>
    align:128 warn_if_not_align:0 context <function_decl 0x7fffe9436100 qy>
    (reg:TI 84 [ fb.3 ])>

fb.3 is introduced by CCP transformation, disabling tree-ccp cures the failure
by adding -fno-tree-ccp.

I suspect that ccp might have a bug that does not mark TREE_ADDRESSABLE
correctly for fb.3.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
commented the following transformation in tree-ssa-ccp.c:

2733 #if 0
2734         /* The heuristic of fold_builtin_alloca_with_align differs before
and
2735            after inlining, so we don't require the arg to be changed into
a
2736            constant for folding, but just to be constant.  */
2737         if (gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
2738             || gimple_call_builtin_p (stmt,
BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
2739           {
2740             tree new_rhs = fold_builtin_alloca_with_align (stmt);
2741             if (new_rhs)
2742               {
2743                 gimplify_and_update_call_from_tree (gsi, new_rhs);
2744                 tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
2745                 insert_clobbers_for_var (*gsi, var);
2746                 return true;
2747               }
2748           }
2749 #endif

cures the ICE.  "fb.3" is a new temp variable that is created inside
"fold_builtin_alloca_with_align".

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to qinzhao from comment #10)

> 2734         /* The heuristic of fold_builtin_alloca_with_align differs

git blame says:


13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2732)         /*
The heuristic of fold_builtin_alloca_with_align differs before and
13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2733)      
after inlining, so we don't require the arg to be changed into a
13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2734)      
constant for folding, but just to be constant.  */
9e878cf1bae7 (Eric Botcazou          2017-10-19 15:58:05 +0000 2735)         if
(gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
9e878cf1bae7 (Eric Botcazou          2017-10-19 15:58:05 +0000 2736)        ||
gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
1fed1006552c (Tom de Vries           2011-08-31 07:04:25 +0000 2737)          
{
13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2738)           
 tree new_rhs = fold_builtin_alloca_with_align (stmt);
5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2739)           
 if (new_rhs)
5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2740)          {
52a5515ed661 (Richard Biener         2021-04-14 13:40:58 +0200 2741)       
gimplify_and_update_call_from_tree (gsi, new_rhs);
2f31f742a693 (Tom de Vries           2011-12-17 11:39:43 +0000 2742)       
tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
2f31f742a693 (Tom de Vries           2011-12-17 11:39:43 +0000 2743)       
insert_clobbers_for_var (*gsi, var);
5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2744)       
return true;
5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2745)          }
1fed1006552c (Tom de Vries           2011-08-31 07:04:25 +0000 2746)          
}

so at least Tom, Eric and Richard have been in there.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
with the following change, I can resolve the ICE:

[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index 70ce6a4d5b8d..b07026165075 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -2655,6 +2655,7 @@ fold_builtin_alloca_with_align (gimple *stmt)
     SET_DECL_PT_UID (var, uid);

   /* Fold alloca to the address of the array.  */
+  mark_addressable (var);
   return fold_convert (TREE_TYPE (lhs), build_fold_addr_expr (var));
 }

diff --git a/gcc/tree-ssa.c b/gcc/tree-ssa.c
index 0fba404babe9..e06609861bf1 100644
--- a/gcc/tree-ssa.c
+++ b/gcc/tree-ssa.c
@@ -1657,7 +1657,7 @@ maybe_optimize_var (tree var, bitmap addresses_taken,
bitmap not_reg_needs,
   bool maybe_reg = false;
   if (TREE_ADDRESSABLE (var))
     {
-      TREE_ADDRESSABLE (var) = 0;
+      //TREE_ADDRESSABLE (var) = 0;
       maybe_reg = true;
       if (dump_file)
        {


However, I am not very sure the change in tree-ssa.c. why TREE_ADDRESSABLE
(var) is reverted in this routine?

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Because the variable doesn't need to be addressable.

OK, so the issue is likely that we're probing the lhs with EXPAND_WRITE but
when we expand the memset we end up with using expand_expr_addr_expr_1
with EXPAND_NORMAL.  So our probe ends up with

(mem/c:BLK (plus:DI (reg/f:DI 77 virtual-stack-vars)
        (const_int -16 [0xfffffffffffffff0])) [0  S-1 A128])

which means it created a stack slot - that's not what we intended.

We could try sth like the following which should cover this testcase and
also hopefully doesn't break anything else.

diff --git a/gcc/expr.c b/gcc/expr.c
index e0bcbccd905..ab3b5b26c20 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -5322,7 +5322,7 @@ non_mem_decl_p (tree base)
 /* Returns true if REF refers to an object that does not
    reside in memory and has non-BLKmode.  */

-static inline bool
+bool
 mem_ref_refers_to_non_mem_p (tree ref)
 {
   tree base;
diff --git a/gcc/expr.h b/gcc/expr.h
index 94a85b40dca..85650e96834 100644
--- a/gcc/expr.h
+++ b/gcc/expr.h
@@ -346,4 +346,6 @@ extern void expand_operands (tree, tree, rtx, rtx*, rtx*,
 /* Return an rtx for the size in bytes of the value of an expr.  */
 extern rtx expr_size (tree);

+extern bool mem_ref_refers_to_non_mem_p (tree ref);
+
 #endif /* GCC_EXPR_H */
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 8312d08aab2..c1d23dfd21e 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3015,8 +3015,10 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
     reg_lhs = true;
   else
     {
-      rtx tem = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE);
-      reg_lhs = !MEM_P (tem);
+      tree lhs_base = lhs;
+      while (handled_component_p (lhs_base))
+       lhs_base = TREE_OPERAND (lhs_base, 0);
+      reg_lhs = mem_refers_to_non_mem_p (lhs_base);
     }

   if (!reg_lhs)

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |egallager at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |vries at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=82421

--- Comment #14 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to David Binderman from comment #11)
> (In reply to qinzhao from comment #10)
> 
> > 2734         /* The heuristic of fold_builtin_alloca_with_align differs
> 
> git blame says:
> 
> 
> 13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2732)        
> /* The heuristic of fold_builtin_alloca_with_align differs before and
> 13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2733)      
> after inlining, so we don't require the arg to be changed into a
> 13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2734)      
> constant for folding, but just to be constant.  */
> 9e878cf1bae7 (Eric Botcazou          2017-10-19 15:58:05 +0000 2735)        
> if (gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
> 9e878cf1bae7 (Eric Botcazou          2017-10-19 15:58:05 +0000 2736)       
> || gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
> 1fed1006552c (Tom de Vries           2011-08-31 07:04:25 +0000 2737)        
> {
> 13e49da934e9 (Tom de Vries           2011-10-07 12:49:49 +0000 2738)        
> tree new_rhs = fold_builtin_alloca_with_align (stmt);
> 5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2739)        
> if (new_rhs)
> 5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2740)        
> {
> 52a5515ed661 (Richard Biener         2021-04-14 13:40:58 +0200 2741)       
> gimplify_and_update_call_from_tree (gsi, new_rhs);
> 2f31f742a693 (Tom de Vries           2011-12-17 11:39:43 +0000 2742)       
> tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
> 2f31f742a693 (Tom de Vries           2011-12-17 11:39:43 +0000 2743)       
> insert_clobbers_for_var (*gsi, var);
> 5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2744)       
> return true;
> 5d882cc1dafe (Richard Guenther       2011-09-02 11:53:55 +0000 2745)        
> }
> 1fed1006552c (Tom de Vries           2011-08-31 07:04:25 +0000 2746)        
> }
> 
> so at least Tom, Eric and Richard have been in there.

cc-ing them

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #15 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> Because the variable doesn't need to be addressable.
> 
> OK, so the issue is likely that we're probing the lhs with EXPAND_WRITE but
> when we expand the memset we end up with using expand_expr_addr_expr_1
> with EXPAND_NORMAL. 

then can we change the probing to use EXPAND_NORMAL?

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qing.zhao at oracle dot com]

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

--- Comment #16 from Qing Zhao <qing.zhao at oracle dot com> ---
> On Oct 1, 2021, at 1:51 AM, rguenth at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
> 
> --- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
> Because the variable doesn't need to be addressable.

One question:

For the following statement in the routine “fold_builtin_alloca_with_align” in
tree-ssa-ccp.c:


  /* Fold alloca to the address of the array.  */
  return fold_convert (TREE_TYPE (lhs), build_fold_addr_expr (var));

Clearly, we build a add_expr for “var”, but why not “mark_addressable” for
“var” since its address is taken?

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #17 from qinzhao at gcc dot gnu.org ---

> > OK, so the issue is likely that we're probing the lhs with EXPAND_WRITE but
> > when we expand the memset we end up with using expand_expr_addr_expr_1
> > with EXPAND_NORMAL. 
> 
> then can we change the probing to use EXPAND_NORMAL?

I tried to change EXPAND_WRITE to EXPAND_NORMAL when probing the lhs, the
exactly the same issue as before.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #18 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> We could try sth like the following which should cover this testcase and
> also hopefully doesn't break anything else.
> 
> diff --git a/gcc/expr.c b/gcc/expr.c
> index e0bcbccd905..ab3b5b26c20 100644
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -5322,7 +5322,7 @@ non_mem_decl_p (tree base)
>  /* Returns true if REF refers to an object that does not
>     reside in memory and has non-BLKmode.  */
>  
> -static inline bool
> +bool
>  mem_ref_refers_to_non_mem_p (tree ref)
>  {
>    tree base;
> diff --git a/gcc/expr.h b/gcc/expr.h
> index 94a85b40dca..85650e96834 100644
> --- a/gcc/expr.h
> +++ b/gcc/expr.h
> @@ -346,4 +346,6 @@ extern void expand_operands (tree, tree, rtx, rtx*, rtx*,
>  /* Return an rtx for the size in bytes of the value of an expr.  */
>  extern rtx expr_size (tree);
>  
> +extern bool mem_ref_refers_to_non_mem_p (tree ref);
> +
>  #endif /* GCC_EXPR_H */
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 8312d08aab2..c1d23dfd21e 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -3015,8 +3015,10 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
>      reg_lhs = true;
>    else
>      {
> -      rtx tem = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE);
> -      reg_lhs = !MEM_P (tem);
> +      tree lhs_base = lhs;
> +      while (handled_component_p (lhs_base))
> +       lhs_base = TREE_OPERAND (lhs_base, 0);
> +      reg_lhs = mem_refers_to_non_mem_p (lhs_base);
>      }
>  
>    if (!reg_lhs)

I tried the above patch, it even doesn't work for this testing case. 
After the patch, this call to .DEFERRED_INIT will be expanded through REG path,
however, the existing problem in the LHS IR broke the "expand_assignment" too. 
so, I still think that the root cause is the IR for LHS of the following call
to .DEFERRED_INIT is not correct:

MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);

the LHS is: MEM[(int[0:D.1993] *)&fb.3]

this is the MEM_REF, whose base address is a ADDR_EXPR of a VAR_DECL, however,
this VAR_DECL is not addressable, will be in REG. this is conflicting: how can
a variable that in a REG be address taken?

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenther at suse dot de]

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

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 1 Oct 2021, qing.zhao at oracle dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
> 
> --- Comment #16 from Qing Zhao <qing.zhao at oracle dot com> ---
> > On Oct 1, 2021, at 1:51 AM, rguenth at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org> wrote:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
> > 
> > --- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
> > Because the variable doesn't need to be addressable.
> 
> One question:
> 
> For the following statement in the routine “fold_builtin_alloca_with_align” in
> tree-ssa-ccp.c:
> 
> 
>   /* Fold alloca to the address of the array.  */
>   return fold_convert (TREE_TYPE (lhs), build_fold_addr_expr (var));
> 
> Clearly, we build a add_expr for “var”, but why not “mark_addressable” for
> “var” since its address is taken?

The address will be propagated and the operand scanner will mark it
addressable when it ends in a context where it needs to be.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenther at suse dot de]

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

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 1 Oct 2021, qinzhao at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
> 
> --- Comment #18 from qinzhao at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #13)
> > We could try sth like the following which should cover this testcase and
> > also hopefully doesn't break anything else.
> > 
> > diff --git a/gcc/expr.c b/gcc/expr.c
> > index e0bcbccd905..ab3b5b26c20 100644
> > --- a/gcc/expr.c
> > +++ b/gcc/expr.c
> > @@ -5322,7 +5322,7 @@ non_mem_decl_p (tree base)
> >  /* Returns true if REF refers to an object that does not
> >     reside in memory and has non-BLKmode.  */
> >  
> > -static inline bool
> > +bool
> >  mem_ref_refers_to_non_mem_p (tree ref)
> >  {
> >    tree base;
> > diff --git a/gcc/expr.h b/gcc/expr.h
> > index 94a85b40dca..85650e96834 100644
> > --- a/gcc/expr.h
> > +++ b/gcc/expr.h
> > @@ -346,4 +346,6 @@ extern void expand_operands (tree, tree, rtx, rtx*, rtx*,
> >  /* Return an rtx for the size in bytes of the value of an expr.  */
> >  extern rtx expr_size (tree);
> >  
> > +extern bool mem_ref_refers_to_non_mem_p (tree ref);
> > +
> >  #endif /* GCC_EXPR_H */
> > diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> > index 8312d08aab2..c1d23dfd21e 100644
> > --- a/gcc/internal-fn.c
> > +++ b/gcc/internal-fn.c
> > @@ -3015,8 +3015,10 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
> >      reg_lhs = true;
> >    else
> >      {
> > -      rtx tem = expand_expr (lhs, NULL_RTX, VOIDmode, EXPAND_WRITE);
> > -      reg_lhs = !MEM_P (tem);
> > +      tree lhs_base = lhs;
> > +      while (handled_component_p (lhs_base))
> > +       lhs_base = TREE_OPERAND (lhs_base, 0);
> > +      reg_lhs = mem_refers_to_non_mem_p (lhs_base);
> >      }
> >  
> >    if (!reg_lhs)
> 
> I tried the above patch, it even doesn't work for this testing case. 
> After the patch, this call to .DEFERRED_INIT will be expanded through REG path,
> however, the existing problem in the LHS IR broke the "expand_assignment" too. 
> so

I see.

> , I still think that the root cause is the IR for LHS of the following 
call
> to .DEFERRED_INIT is not correct:
>
> MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);
> 
> the LHS is: MEM[(int[0:D.1993] *)&fb.3]
> 
> this is the MEM_REF, whose base address is a ADDR_EXPR of a VAR_DECL, however,
> this VAR_DECL is not addressable, will be in REG. this is conflicting: how can
> a variable that in a REG be address taken?

It doesn't have its address taken - the ADDR_EXPR is artificial when
at the base of a MEM_REF.

Let me thake this bug then.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
Reduced testcase:

int
qy (void)
{
  int tw = 4;
  int fb[tw];
  return fb[2];
}

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenth at gcc dot gnu.org]

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

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, my proposed patch seems to work.  I've adjusted it to not regress
previously correctly handled cases and will test it fully.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
I do have to check the result before this fix attempt but at least with it
the overall testsuite state isn't so great.  You can do

make check RUNTESTFLAGS="--target_board=unix/-ftrivial-auto-var-init=zer"

to check all of the testsuite (besides Ada ACATS which doesn't honor
RUNTESTFLAGS, you have to edit gcc/testsuite/ada/acats/run_all.sh and
amend the toplevel 'gccflags' variable there.

I see ICEs and runfails there.  I'll file a separate bug about these
(some may be due to the DECL_VALUE_EXPR thing).

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
commit 7e0c0500808d58bca5b8e23cbd474022c32234e4 (origin/master, origin/HEAD)
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Oct 4 11:34:27 2021 +0200

    middle-end/102285 - refine .DEFERRED_INIT expansion

    This refines the way we figure whether we are facing a register
    that cannot be initialized by emitting a memset away from inspecting
    expanded RTL of the LHS to using the predicates expand_assignment
    is using to detect decls or MEM_REFs with non-memory DECL_RTL.

    2021-10-04  Richard Biener  <rguenther@suse.de>

            * expr.h (non_mem_decl_p): Declare.
            (mem_ref_refers_to_non_mem_p): Likewise.
            * expr.c (non_mem_decl_p): Export.
            (mem_ref_refers_to_non_mem_p): Likewise.
            * internal-fn.c (expand_DEFERRED_INIT): Do not expand the LHS
            but check the base with mem_ref_refers_to_non_mem_p
            and non_mem_decl_p.

            * c-c++-common/pr102285.c: New testcase.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #22)
> Hmm, my proposed patch seems to work.  I've adjusted it to not regress
> previously correctly handled cases and will test it fully.

I guess the reason for it worked for you because you tested it after the patch
for 102587?

--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3035,7 +3035,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
       /* Expand this memset call.  */
       expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type));
     }
-  else
+  /* ???  Deal with poly-int sized registers.  */
+  else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))
     {
       /* If this variable is in a register, use expand_assignment might
         generate better code.  */

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #26 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #25)
> (In reply to Richard Biener from comment #22)
> > Hmm, my proposed patch seems to work.  I've adjusted it to not regress
> > previously correctly handled cases and will test it fully.
> 
> I guess the reason for it worked for you because you tested it after the
> patch for 102587?
> 
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -3035,7 +3035,8 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
>        /* Expand this memset call.  */
>        expand_builtin_memset (m_call, NULL_RTX, TYPE_MODE (var_type));
>      }
> -  else
> +  /* ???  Deal with poly-int sized registers.  */
> +  else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))
>      {
>        /* If this variable is in a register, use expand_assignment might
>          generate better code.  */

because for the following IR:

 MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);

The "var_type" of the LHS is "int[0:D.1993]", which is not an integer constant
(even though the type for fb.3 should be the new type for the new temporary
variable char[16]). 

As a result, the new added check
> +  /* ???  Deal with poly-int sized registers.  */
> +  else if (tree_fits_uhwi_p (TYPE_SIZE_UNIT (var_type)))

excluded it from expanding through expand_assign.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

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

--- Comment #27 from qinzhao at gcc dot gnu.org ---
since the call to 

MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);

is NOT expanded at all during RTL expansion phase, The auto variable "int
fb[tw]";

is not initialized to zero with this patch, which is not what we want.

So, I think that we might need to reconsider the patch for this bug.

I'm reopening this bug for a further discussion.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[qinzhao at gcc dot gnu.org]

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

--- Comment #28 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
> Reduced testcase:
> 
> int
> qy (void)
> {
>   int tw = 4;
>   int fb[tw];
>   return fb[2];
> }

For this reduced testing case, if compiled with 
/home/opc/Install/latest/bin/gcc -c -O -ftrivial-auto-var-init=zero
-fdump-tree-all t.c

******t.c.032t.cpp1:
int qy (int l9)
{
  unsigned char fb.3[16];
  int tw;
  int[0:D.1984] * fb.1;
  sizetype D.1984;
  void * saved_stack.2_16;
  int _27;

  <bb 2> :
  saved_stack.2_16 = __builtin_stack_save ();
  fb.1_25 = &fb.3;
  (*fb.1_25) = .DEFERRED_INIT (16, 2, 1);
  _27 = (*fb.1_25)[2];
  ..
}

******t.c.033t.forwprop1:
int qy (int l9)
{
  unsigned char fb.3[16];
  int tw;
  int[0:D.1984] * fb.1;
  sizetype D.1984;
  void * saved_stack.2_16;
  int _27;

  <bb 2> :
  saved_stack.2_16 = __builtin_stack_save ();
  MEM[(int[0:D.1984] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);
  _27 = MEM[(int[0:D.1984] *)&fb.3][2];
  ..
}

the problem with the above IR for .DEFERRED_INIT expansion is:

for MEM[(int[0:D.1984] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);

after the "ccp" and "forwprop", the original VLA *fb.1 is replaced with the the
new fixed array &fb.3, however, the VAR_TYPE still is the old VLA type
int[0:D.1984]. if we can replace the var_type to the new "unsigned char [16]"
for both the LHS and the call to .DEFERRED_INIT. then expansion through
assign_expand should work.

We might need to special handling the LHS to get the new type for "fb.3"
instead of the old "var_type" for "assign_expand".

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #29 from CVS 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:604459a09585314841cdce4698893c656481691b

commit r12-4182-g604459a09585314841cdce4698893c656481691b
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Oct 5 09:28:20 2021 +0200

    More .DEFERRED_INIT expansion rework

    This avoids looking at the type size and instead uses the size
    as passed to .DEFERRED_INIT to determine the size of the non-MEM
    to be initialized.  It also arranges for possibly poly-int
    inits to always use zero-initialization rather than not initializing
    and when we need to pun puns the LHS instead of the constant value.

    That correctly initializes the variable-size typed array in the
    testcase for PR102285 and the SVE vector in PR102587 where for
    the testcase I needed to add a SVE capable -march as to not
    ICE later.

    2021-10-05  Richard Biener  <rguenther@suse.de>

            PR middle-end/102587
            PR middle-end/102285
            * internal-fn.c (expand_DEFERRED_INIT): Fall back to
            zero-initialization as last resort, use the constant
            size as given by the DEFERRED_INIT argument to build
            the initializer.

            * gcc.target/aarch64/sve/pr102587-1.c: Add -march=armv8.3-a+sve.
            * gcc.target/aarch64/sve/pr102587-2.c: Likewise.

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.