[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64

["qinzhao at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #8 from qinzhao at gcc dot gnu.org ---
the minimum option to repeat this failure is "-O1 -mno-strict-align".

The option "-mno-strict-align" is the one that make the difference. 

For the following call to .DEFERRED_INIT:

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

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

When -mno-strict-align is NOT present, "mem_ref_refers_to_non_mem_p (lhs_base)"
return FALSE, lHS is considered as MEM, and the call is expanded through
"memset" path. No issue.

when -mno-strict-align is present, "mem_ref_refers_to_non_mem_p (lhs_base)"
return TRUE, as a result, LHS is considered to be put into a register, and then
the call is expanded through "expand_assignment" path. 

The major issue during expanding through "expand_assignment" path is:

although the LHS "MEM[(int[0:D.1492] *)&fb.3]" is decided to be put into
register with TI mode, however, the TREE_TYPE of LHS is still a VLA type, such
inconsistency in IR cause the final ICE.

with the option -mno-strict-align, the IR of lhs_base is:

(gdb) call debug_tree(lhs_base)
 <mem_ref 0x7ffff082bc08
    type <array_type 0x7ffff082cb28
        type <integer_type 0x7ffff07465e8 int sizes-gimplified public SI
            size <integer_cst 0x7ffff0739bb8 constant 32>
            unit-size <integer_cst 0x7ffff0739bd0 constant 4>
            align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7ffff07465e8 precision:32 min <integer_cst 0x7ffff0739b70 -2147483648> max
<integer_cst 0x7ffff0739b88 2147483647>
            pointer_to_this <pointer_type 0x7ffff074d9d8>>
        sizes-gimplified type_1 BLK
        size <var_decl 0x7ffff7ff0360 D.1495 type <integer_type 0x7ffff07460a8
bitsizetype>        
            used unsigned ignored TI t.c:8:7 
            size <integer_cst 0x7ffff07399c0 constant 128>
            unit-size <integer_cst 0x7ffff07399d8 constant 16>
            align:128 warn_if_not_align:0 context <function_decl 0x7ffff0830500
qy>>
        unit-size <var_decl 0x7ffff7ff03f0 D.1496 type <integer_type
0x7ffff0746000 sizetype>
            used unsigned ignored DI t.c:8:7
            size <integer_cst 0x7ffff0739978 constant 64>
            unit-size <integer_cst 0x7ffff0739990 constant 8>
            align:64 warn_if_not_align:0 context <function_decl 0x7ffff0830500
qy>>
        align:32 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality
        domain <integer_type 0x7ffff082ca80 type <integer_type 0x7ffff0746000
sizetype>
            sizes-gimplified DI size <integer_cst 0x7ffff0739978 64> unit-size
<integer_cst 0x7ffff0739990 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality precision:64 min <integer_cst 0x7ffff07399a8 0> max
<var_decl 0x7ffff7ff02d0 D.1494>>
        pointer_to_this <pointer_type 0x7ffff082cbd0>>
    nothrow
    arg:0 <addr_expr 0x7ffff082e7e0
        type <pointer_type 0x7ffff082c2a0 type <array_type 0x7ffff082c1f8>
            unsigned DI size <integer_cst 0x7ffff0739978 64> unit-size
<integer_cst 0x7ffff0739990 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff082c2a0>

        arg:0 <var_decl 0x7ffff7ff0990 fb.3 type <array_type 0x7ffff082c1f8>
            used ignored TI t.c:8:7 size <integer_cst 0x7ffff07399c0 128>
unit-size <integer_cst 0x7ffff07399d8 16>
            align:64 warn_if_not_align:0 context <function_decl 0x7ffff0830500
qy>
            (reg:TI 72 [ fb.3 ])>>
    arg:1 <integer_cst 0x7ffff0836fd8 type <pointer_type 0x7ffff082cbd0>
constant 0>
    t.c:8:7 start: t.c:8:7 finish: t.c:8:8>

>From the above IR, we can see,

1. the base address of this mem_ref is 

        arg:0 <var_decl 0x7ffff7ff0990 fb.3 type <array_type 0x7ffff082c1f8>
            used ignored TI t.c:8:7 size <integer_cst 0x7ffff07399c0 128>
unit-size <integer_cst 0x7ffff07399d8 16>
            align:64 warn_if_not_align:0 context <function_decl 0x7ffff0830500
qy>
            (reg:TI 72 [ fb.3 ])>>

which is in register of TI mode;

2. However, the TREE_TYPE of this mem_ref is still a VLA type.

when call "build_zero_cst (var_type)", the var_type is a VLA type, therefore
the ICE. 


My suspicion is, -mno-strict-align applied some kind of optimization that turn
the var_decl from: 

        arg:0 <var_decl 0x7ffff7ff0990 fb.3 type <array_type 0x7ffff082c1f8>
            used ignored BLK t.c:8:7 size <integer_cst 0x7ffff07399c0 128>
unit-size <integer_cst 0x7ffff07399d8 16>
            align:128 warn_if_not_align:0 context <function_decl 0x7ffff0830500
qy>
            (mem/c:BLK (plus:DI (reg/f:DI 67 virtual-stack-vars)
        (const_int -16 [0xfffffffffffffff0])) [0 fb.3+0 S16 A128])>>

to:
        arg:0 <var_decl 0x7ffff7ff0990 fb.3 type <array_type 0x7ffff082c1f8>
            used ignored TI t.c:8:7 size <integer_cst 0x7ffff07399c0 128>
unit-size <integer_cst 0x7ffff07399d8 16>
            align:64 warn_if_not_align:0 context <function_decl 0x7ffff0830500
qy>
            (reg:TI 72 [ fb.3 ])>>


However, the TREE_TYPE of MEM[(int[0:D.1492] *)&fb.3] is not updated
accordingly.