[Bug target/103271] New: ICE in assign_stack_temp_for_type, at function.c:798

[Bug target/103271] New: ICE in assign_stack_temp_for_type, at function.c:798

[marxin at gcc dot gnu.org]

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

            Bug ID: 103271
           Summary: ICE in assign_stack_temp_for_type, at function.c:798
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: qing.zhao at oracle dot com, rguenth at gcc dot gnu.org
  Target Milestone: ---
              Host: x86_64-linux-gnu
            Target: riscv64-unknown-linux-gnu

The following ICEs:

$ riscv64-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr102285.c -Ofast
-ftrivial-auto-var-init=pattern -mno-strict-align
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr102285.c: In function
'qy':
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/pr102285.c:8:7:
internal compiler error: in assign_stack_temp_for_type, at function.c:798
    8 |   int fb[tw];
      |       ^~
0x5dd2da assign_stack_temp_for_type(machine_mode, poly_int<1u, long>,
tree_node*)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/function.c:798
0x87b194 assign_temp(tree_node*, int, int)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/function.c:1018
0x839fcc expand_constructor
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/expr.c:8657
0x82b777 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/expr.c:10845
0x839652 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/expr.c:8739
0x839652 expand_normal
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/expr.h:307
0x839652 store_field
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/expr.c:7465
0x8368f7 expand_assignment(tree_node*, tree_node*, bool)
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/expr.c:5682
0x8fab7d expand_DEFERRED_INIT
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/internal-fn.c:3104
0x72f507 expand_call_stmt
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:2749
0x72f507 expand_gimple_stmt_1
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:3876
0x72f507 expand_gimple_stmt
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:4040
0x733a77 expand_gimple_basic_block
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:6082
0x735aa6 execute
       
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-riscv64/build/gcc/cfgexpand.c:6808
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/103271] ICE in assign_stack_temp_for_type, at function.c:798

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-11-16

[Bug target/103271] ICE in assign_stack_temp_for_type, at function.c:798

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.0                        |---

[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]

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

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 ---
was not able to repeat this failure yet due to:

1. cannot find a riscv machine either in my company or in gcc farm.
2. tried to build a cross-compiler on riscv64 from a x86 platform, but always
failed.

is there a good documentation to build cross-compiler?

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

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to qinzhao from comment #1)
> was not able to repeat this failure yet due to:
> 
> 1. cannot find a riscv machine either in my company or in gcc farm.
> 2. tried to build a cross-compiler on riscv64 from a x86 platform, but
> always failed.

It's as simple as:

$ ../configure --enable-languages=c,c++ --disable-multilib
--disable-libsanitizer --disable-bootstrap --target=riscv64-linux-gnu
$ make all-host

> 
> is there a good documentation to build cross-compiler?

https://gcc.gnu.org/install/build.html#Building-a-cross-compiler

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

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 22 Nov 2021, qinzhao at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
> 
> 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 ---
> was not able to repeat this failure yet due to:
> 
> 1. cannot find a riscv machine either in my company or in gcc farm.
> 2. tried to build a cross-compiler on riscv64 from a x86 platform, but always
> failed.
> 
> is there a good documentation to build cross-compiler?

You should be able to simply do

 ../configure --target=riscv64-linux
 make all-gcc

and use the built gcc/cc1 to debug such ICEs.

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

[qing.zhao at oracle dot com]

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

--- Comment #4 from Qing Zhao <qing.zhao at oracle dot com> ---
> 
> You should be able to simply do
> 
> ../configure --target=riscv64-linux
> make all-gcc
> 
> and use the built gcc/cc1 to debug such ICEs.
> 

Thanks. Yes, I can repeat the ICE with this gcc even though “make install”
still failed with the following error:

make[2]: Leaving directory '/home/opc/Work/GCC/crossbuild/libiberty'
/bin/sh: line 3: cd: ./c++tools: No such file or directory
make[1]: *** [Makefile:12252: install-c++tools] Error 1
make[1]: Leaving directory '/home/opc/Work/GCC/crossbuild'
make: *** [Makefile:2538: install] Error 2

Anyway, I can debug this current bug with this gcc now.

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

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

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

--- Comment #5 from Jim Wilson <wilson at gcc dot gnu.org> ---
SiFive doesn't support -mno-strict-align so I've never tested it.  I doubt that
it works correctly, i.e. I doubt that it optimizes as intended.  I've mentioned
this to other RVI members, but there hasn't been anyone other than SiFive
actively working on upstream gcc so I don't think anyone ever looked at it.  It
shouldn't give an ICE though.

Looking at this, it appears to be another "if only we had a movti pattern"
issue.

In expand_DEFERRED_INIT in internal-fn.c, in the reg_lhs == TRUE case, there is
a test
          && have_insn_for (SET, var_mode))
which fails because var_mode is TImode and we don't have a movti pattern.  The
code calls build_zero_cst which returns a constructor with an array type.  We
then call expand_assignment which gets confused as it doesn't know the size of
the array it is copying.

However, if we had a movti pattern, then the code computes the size of the
array, and creates a VIEW_CONVERT_EXPR to document the array size before
calling expand_assignment.  So it looks like it would work if we had a movti
pattern.

I verified that adding a dummy movti pattern makes the ICE go away.

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

[wilson at gcc dot gnu.org]

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

--- Comment #6 from Jim Wilson <wilson at gcc dot gnu.org> ---
See also bug 103302 which can also be fixed by adding a movti pattern.

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

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 26 Nov 2021, wilson at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
> 
> Jim Wilson <wilson at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |wilson at gcc dot gnu.org
> 
> --- Comment #5 from Jim Wilson <wilson at gcc dot gnu.org> ---
> SiFive doesn't support -mno-strict-align so I've never tested it.  I doubt that
> it works correctly, i.e. I doubt that it optimizes as intended.  I've mentioned
> this to other RVI members, but there hasn't been anyone other than SiFive
> actively working on upstream gcc so I don't think anyone ever looked at it.  It
> shouldn't give an ICE though.
> 
> Looking at this, it appears to be another "if only we had a movti pattern"
> issue.
> 
> In expand_DEFERRED_INIT in internal-fn.c, in the reg_lhs == TRUE case, there is
> a test
>           && have_insn_for (SET, var_mode))
> which fails because var_mode is TImode and we don't have a movti pattern.  The
> code calls build_zero_cst which returns a constructor with an array type.  We
> then call expand_assignment which gets confused as it doesn't know the size of
> the array it is copying.

That seems to be the bug - in this path we shouldn't ever create an
entity with VLA size since we do know the actual size.  But it all
is a bit awkward.

[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]

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.

[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]

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
disable tree-ccp by adding -fno-tree-ccp cures the ICE.

[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]

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
looks like that this is exactly the same issue as exposed in pr102285.

and the original fix to pr102285 just hide this inconsistent IR issue.

-mno-strict-align exposed this issue again.

So. I believe that we need to fix the inconsistent IR issue in order to
completely resolve this issue.

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

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org,
                   |                            |law at gcc dot gnu.org

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to qinzhao from comment #10)
> looks like that this is exactly the same issue as exposed in pr102285.
> 
> and the original fix to pr102285 just hide this inconsistent IR issue.
> 
> -mno-strict-align exposed this issue again.
> 
> So. I believe that we need to fix the inconsistent IR issue in order to
> completely resolve this issue.

The issue is simply that using build_zero_cst is "wrong" here in the sense
that we know the size is constant but we hide that fact.

In fact, C disallows initializing variable-sized objects, so an adjusted
testcase with

 int fb[tw] = {};

is not valid C.  I think the situation with risc-v is unfortunate since
all other places in the compiler that zero non-memory simply use
emit_move_insn from CONST0_RTX but that's not avilable since we do not
go the "correct" path only because have_insn_for (SET, TImode) does not
exist.

But I'm not a target / RTL expert enough to tell whether that's a general
problem that should be fixed.

I also have no idea how to manually generate a proper zeroing sequence
for the (reg:TI ..) pseudo the VLA typed aggregate expands to.

I suppose assigning TImode to a decl but not even being able to move TImode
can be a problem elsewhere...

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

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 6ac3460d538..08f94b7a17a 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3050,6 +3050,23 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
        lhs_base = TREE_OPERAND (lhs_base, 0);
       reg_lhs = (mem_ref_refers_to_non_mem_p (lhs_base)
                 || non_mem_decl_p (lhs_base));
+      /* If this expands to a register and the underlying decl is wrapped in
+        a MEM_REF that just serves as an access type change expose the decl
+        if it is of correct size.  This avoids a situation as in PR103271
+        if the target does not support a direct move to the registers mode. 
*/
+      if (reg_lhs
+         && TREE_CODE (lhs_base) == MEM_REF
+         && TREE_CODE (TREE_OPERAND (lhs_base, 0)) == ADDR_EXPR
+         && DECL_P (TREE_OPERAND (TREE_OPERAND (lhs_base, 0), 0))
+         && integer_zerop (TREE_OPERAND (lhs_base, 1))
+         && tree_fits_uhwi_p (var_size)
+         && tree_int_cst_equal
+              (var_size,
+               DECL_SIZE_UNIT (TREE_OPERAND (TREE_OPERAND (lhs_base, 0), 0))))
+       {
+         lhs = TREE_OPERAND (TREE_OPERAND (lhs_base, 0), 0);
+         var_type = TREE_TYPE (lhs);
+       }
     }

   if (!reg_lhs)

solves the issue.  There might be a situation where that's not enough though,
I'm giving the above some testing.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 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:06b8cdc8d7339ac44802044ef148dd86874333d8

commit r12-5709-g06b8cdc8d7339ac44802044ef148dd86874333d8
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Dec 2 12:23:22 2021 +0100

    middle-end/103271 - avoid VLA init of register

    This avoids using VLA types to initalize a register with
    -ftrivial-auto-var-init in some cases.

    2021-12-02  Richard Biener  <rguenther@suse.de>

            PR middle-end/103271
            * internal-fn.c (expand_DEFERRED_INIT): When the base
            of the LHS is a decl with matching constant size use
            that as the initialization target instead of an
            eventual VLA typed one.

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

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
The specific case is avoided now, still I'm unsure if riscv is "bad" in not
providing moves to TImode pseudos.

[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]

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

--- Comment #15 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
> 
> I suppose assigning TImode to a decl but not even being able to move TImode
> can be a problem elsewhere...

this might be the root issue that we should fix?
as mentioned by Jim in comment #5 and #6, adding a MOVTI pattern in riscv will
fix other bug in addition to this one. so, should the right fix be in riscv
backend?

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

[wilson at gcc dot gnu.org]

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

--- Comment #16 from Jim Wilson <wilson at gcc dot gnu.org> ---
I have a patch to add movti to the riscv port.  I agree that we should be
adding this.  I just unfortunately had a kitchen accident and had take some
time off before I finished it.  I noticed that a comment before
riscv_split_doubleword_move implies that we did used to have a movti pattern. 
I wanted to check out the history before re-adding movti to make sure I didn't
break anything.

[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]

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

--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #12)
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 6ac3460d538..08f94b7a17a 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -3050,6 +3050,23 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
>         lhs_base = TREE_OPERAND (lhs_base, 0);
>        reg_lhs = (mem_ref_refers_to_non_mem_p (lhs_base)
>                  || non_mem_decl_p (lhs_base));
> +      /* If this expands to a register and the underlying decl is wrapped in
> +        a MEM_REF that just serves as an access type change expose the decl
> +        if it is of correct size.  This avoids a situation as in PR103271
> +        if the target does not support a direct move to the registers mode.
> */
> +      if (reg_lhs
> +         && TREE_CODE (lhs_base) == MEM_REF
> +         && TREE_CODE (TREE_OPERAND (lhs_base, 0)) == ADDR_EXPR
> +         && DECL_P (TREE_OPERAND (TREE_OPERAND (lhs_base, 0), 0))
> +         && integer_zerop (TREE_OPERAND (lhs_base, 1))
> +         && tree_fits_uhwi_p (var_size)
> +         && tree_int_cst_equal
> +              (var_size,
> +               DECL_SIZE_UNIT (TREE_OPERAND (TREE_OPERAND (lhs_base, 0),
> 0))))
> +       {
> +         lhs = TREE_OPERAND (TREE_OPERAND (lhs_base, 0), 0);
> +         var_type = TREE_TYPE (lhs);
> +       }
>      }
>  
>    if (!reg_lhs)
> 
> solves the issue.  There might be a situation where that's not enough though,
> I'm giving the above some testing.
this patch is so specific to target this specific case, I am wondering whether
this is needed if Tim will provide a patch to support MOVTI in riscv backend?

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

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kito.cheng at gmail dot com

--- Comment #18 from Jim Wilson <wilson at gcc dot gnu.org> ---
I found the place where the movti patterns were removed.  This is a riscv-gcc
commit from Kito.

commit 38650bdbe91bf37c3cce706ce612097b657a91d5
Author: Kito Cheng <kito.cheng@gmail.com>
Date:   Mon Sep 12 14:52:56 2016 +0800

    Remove 128 bit support, just let gcc handle it

I don't see a github pull request or issue for it, so I don't know why Kito
removed the support.  This is a little too long ago to easily find info related
to the change.  This is a gcc-6.1 source base.  Unless perhaps Kito remembers
why he made the change, all I can do is readd the support and wait to see if
something else breaks.  I do think that we should readd the movti support to
fix a couple of bugs.  I suspect a code size or performance issue, but wrong
code and ICEs are worse problems than code size and performance.