> > +/* Test that we do not have ice when compile */
> > +
> > +/* { dg-do run } */
> > +/* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=zvl -flto 
> > -O2 -fno-checking" } */
> > +
> > +#include <riscv_vector.h>
> > +
> > +int
> > +main ()
> > +{
> > +  size_t vl = 8;
> > +  vint32m1_t vs1 = {};
> > +  vint32m1_t vs2 = {};
> > +
> > +  __volatile__ vint32m1_t vd = __riscv_vadd_vv_i32m1(vs1, vs2, vl);
> > +
> > +  return 0;
> > +}
> 
> Interesting, do we still have ice when there is no __voltaile__ for vd? As 
> well as gcc-14 branch.
> Because it is quite a common case that should be covered by test already.
> 
> Pan

Yes, I am also surprised that this kind of ICE will appear. It really should be 
covered by
test cases. But in fact, if we do not use zvfh or zvfhmin in arch, rvv cannot 
be used in LTO.

This has nothing to do with "__voltaile__". "__voltaile__" in the case is just 
that I want it
to be compiled to the end and not optimized.

In fact, a simple case can reproduce ICE, including gcc-14 and master, for 
example:

#include <riscv_vector.h>

vint32m1_t foo(vint32m1_t vs1, vint32m1_t vs2, size_t vl) 
{
  return __riscv_vadd_vv_i32m1(vs1, vs2, vl);
}

If we compile this case with the option " -march=rv64gcv -mabi=lp64d  -flto 
-O0", we will
get the following error:

during RTL pass: expand
../test.c: In function 'foo':
../test.c:5:10: internal compiler error: tree check: expected tree that 
contains 'typed' structure, have 'ggc_freed' in function_returns_void_p, at 
config/riscv/riscv-vector-builtins.h:456
    5 |   return __riscv_vadd_vv_i32m1(vs1, vs2, vl);
      |          ^
0x4081948 internal_error(char const*, ...)
        /iothome/jin.ma/code/master/gcc/gcc/diagnostic-global-context.cc:492
0x1dc584d tree_contains_struct_check_failed(tree_node const*, 
tree_node_structure_enum, char const*, int, char const*)
        /iothome/jin.ma/code/master/gcc/gcc/tree.cc:9177
0x10d8230 contains_struct_check(tree_node*, tree_node_structure_enum, char 
const*, int, char const*)
        /iothome/jin.ma/code/master/gcc/gcc/tree.h:3779
0x2078f0c riscv_vector::function_call_info::function_returns_void_p()
        
/iothome/jin.ma/code/master/gcc/gcc/config/riscv/riscv-vector-builtins.h:456
0x2074f54 
riscv_vector::function_expander::function_expander(riscv_vector::function_instance
 const&, tree_node*, tree_node*, rtx_def*)
        
/iothome/jin.ma/code/master/gcc/gcc/config/riscv/riscv-vector-builtins.cc:3920
0x20787b8 riscv_vector::expand_builtin(unsigned int, tree_node*, rtx_def*)
        
/iothome/jin.ma/code/master/gcc/gcc/config/riscv/riscv-vector-builtins.cc:4775
0x2029b60 riscv_expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, 
int)
        /iothome/jin.ma/code/master/gcc/gcc/config/riscv/riscv-builtins.cc:433
0x1167cb7 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
        /iothome/jin.ma/code/master/gcc/gcc/builtins.cc:7763
0x137e5d2 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, 
expand_modifier, rtx_def**, bool)
        /iothome/jin.ma/code/master/gcc/gcc/expr.cc:12390
0x1370068 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)
        /iothome/jin.ma/code/master/gcc/gcc/expr.cc:9473
0x136434a store_expr(tree_node*, rtx_def*, int, bool, bool)
        /iothome/jin.ma/code/master/gcc/gcc/expr.cc:6766
0x13629e3 expand_assignment(tree_node*, tree_node*, bool)
        /iothome/jin.ma/code/master/gcc/gcc/expr.cc:6487
0x11a8419 expand_call_stmt
        /iothome/jin.ma/code/master/gcc/gcc/cfgexpand.cc:2893
0x11ac48e expand_gimple_stmt_1
        /iothome/jin.ma/code/master/gcc/gcc/cfgexpand.cc:3962
0x11acaad expand_gimple_stmt
        /iothome/jin.ma/code/master/gcc/gcc/cfgexpand.cc:4104
0x11b55a1 expand_gimple_basic_block
        /iothome/jin.ma/code/master/gcc/gcc/cfgexpand.cc:6160
0x11b7b96 execute
        /iothome/jin.ma/code/master/gcc/gcc/cfgexpand.cc:6899
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error: riscv64-unknown-linux-gnu-gcc returned 1 exit status
compilation terminated.
/mnt/ssd/jin.ma/install/master/bin/../lib/gcc/riscv64-unknown-linux-gnu/15.0.0/../../../../riscv64-unknown-linux-gnu/bin/ld:
 error: lto-wrapper failed
collect2: error: ld returned 1 exit status

This patch tried to fix it, but it didn't fix it completely. If we use 
"-fchecking", we still
have ICE. This has to do with function ggc_grow in the LTO phase. Maybe the fix 
for this ICE
is that we use something like "malloc" instead of "ggc_alloc" for 
"registered_functions",
I'm not sure there is a better way.

If this is a problem and needs to be fixed, I am happy to try to solve it.

Reply via email to