I have tried this:
enum class reduction_type
{
UNORDERED,
FOLD_LEFT,
MASK_LEN_FOLD_LEFT,
};
But fail to build.....
/gcc/build -I../../../riscv-gcc/gcc/../include
-I../../../riscv-gcc/gcc/../libcpp/include -g -O0 \
-o build/gencondmd.o build/gencondmd.cc
In file included from ./tm_p.h:4:0,
from build/gencondmd.cc:29:
../../../riscv-gcc/gcc/config/riscv/riscv-protos.h:294:36: error: could not
convert ‘UNORDERED’ from ‘rtx_code’ to ‘riscv_vector::reduction_type’
reduction_type = UNORDERED);
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-20 16:03
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; gcc-patches; kito.cheng; jeffreyalaw
Subject: Re: Re: [PATCH] RISC-V: Support in-order floating-point reduction
Seems like because you ` using namespace riscv_vector;` so the
UNORDERED in expand_vec_cmp_float used reduction_type::UNORDERED
Hmmm, maybe enum class?
enum class reduction_type
{
UNORDERED,
FOLD_LEFT,
MASK_LEN_FOLD_LEFT,
};
and need use like this reduction_type::UNORDERED
On Thu, Jul 20, 2023 at 3:59 PM juzhe.zh...@rivai.ai
<juzhe.zh...@rivai.ai> wrote:
>
> I have no ideal, just ICE comes when running regression:
>
> during RTL pass: expand
> auto.c: In function 'test_int32_t_float_unordered_var':
> auto.c:24:3: internal compiler error: in expand_vec_cmp_float, at
> config/riscv/riscv-v.cc:2564
> 24 | test_##TYPE1##_##TYPE2##_##CMP##_var (TYPE1 *restrict dest, \
> | ^~~~~
> auto.c:41:3: note: in expansion of macro 'TEST_LOOP'
> 41 | TEST_LOOP (int32_t, float, CMP) \
> | ^~~~~~~~~
> auto.c:55:1: note: in expansion of macro 'TEST_CMP'
> 55 | TEST_CMP (unordered)
> | ^~~~~~~~
> 0x1c8af0d riscv_vector::expand_vec_cmp_float(rtx_def*, rtx_code, rtx_def*,
> rtx_def*, bool)
> ../../../riscv-gcc/gcc/config/riscv/riscv-v.cc:2564
> 0x233d200 gen_vec_cmprvvm1sfrvvmf32bi(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
> ../../../riscv-gcc/gcc/config/riscv/autovec.md:559
> 0x14c4582 rtx_insn* insn_gen_fn::operator()<rtx_def*, rtx_def*, rtx_def*,
> rtx_def*>(rtx_def*, rtx_def*, rtx_def*, rtx_def*) const
> ../../../riscv-gcc/gcc/recog.h:407
> 0x14c3c02 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
> ../../../riscv-gcc/gcc/optabs.cc:8197
> 0x14c4097 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
> ../../../riscv-gcc/gcc/optabs.cc:8237
> 0x14c412b expand_insn(insn_code, unsigned int, expand_operand*)
> ../../../riscv-gcc/gcc/optabs.cc:8268
> 0x14bfc3e expand_vec_cmp_expr(tree_node*, tree_node*, rtx_def*)
> ../../../riscv-gcc/gcc/optabs.cc:6692
> 0x1124e4a do_store_flag
> ../../../riscv-gcc/gcc/expr.cc:13060
> 0x1116b10 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
> ../../../riscv-gcc/gcc/expr.cc:10265
> 0x1119405 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
> ../../../riscv-gcc/gcc/expr.cc:10810
> 0x1110fb0 expand_expr_real(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
> ../../../riscv-gcc/gcc/expr.cc:9015
> 0xf2e973 expand_normal(tree_node*)
> ../../../riscv-gcc/gcc/expr.h:316
> 0x12bb060 expand_vec_cond_mask_optab_fn
> ../../../riscv-gcc/gcc/internal-fn.cc:3059
> 0x12c27ca expand_VCOND_MASK
> ../../../riscv-gcc/gcc/internal-fn.def:184
> 0x12c52a5 expand_internal_call(internal_fn, gcall*)
> ../../../riscv-gcc/gcc/internal-fn.cc:4792
> 0x12c52d0 expand_internal_call(gcall*)
> ../../../riscv-gcc/gcc/internal-fn.cc:4800
> 0xf5e4c1 expand_call_stmt
> ../../../riscv-gcc/gcc/cfgexpand.cc:2737
> 0xf62871 expand_gimple_stmt_1
> ../../../riscv-gcc/gcc/cfgexpand.cc:3880
> 0xf62f0f expand_gimple_stmt
> ../../../riscv-gcc/gcc/cfgexpand.cc:4044
> 0xf6b8a9 expand_gimple_basic_block
> ../../../riscv-gcc/gcc/cfgexpand.cc:6096
>
> This ICE happens when compiling vcond.cc tests
> ________________________________
> juzhe.zh...@rivai.ai
>
>
> From: Robin Dapp
> Date: 2023-07-20 15:57
> To: juzhe.zh...@rivai.ai; gcc-patches
> CC: rdapp.gcc; kito.cheng; Kito.cheng; jeffreyalaw
> Subject: Re: [PATCH] RISC-V: Support in-order floating-point reduction
> > The UNORDERED enum will cause ICE since we have UNORDERED in rtx_code.
> >
> > Could you give me another enum name?
>
> I would have expected it to work when it's namespaced.
>
> Regards
> Robin
>
>
