All failures with (test for excess errors) are not big issues which are created by testcase themselves.

For example:
FAIL: g++.target/riscv/rvv/base/bug-14.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-9.C (test for excess errors)
These 2 failures are because RV32 doesn't have indexed load/store with indexed EEW = 64.
Like __riscv_vsuxei64_v_i32mf2    in bug-14.C, this intrinsic is valid in RV64 but invalid in RV32 which
is totally correct since according to RVV ISA:
The V extension supports all vector load and store instructions (Section Vector Loads and Stores), except the V extension does not support EEW=64 for index values when XLEN=32.

So these 2 failures in RV32 are not the compile's bugs. I have seen:  /* { dg-do run { target { { {riscv_vector} && {rv64} } } } } */
in these testcases which can not work to block execution in RV32 (Since such testcase only needs to be tested on RV64). I think this is the issue we need to figure out.

So, to conclude:
All these failures:
                === gcc: Unexpected fails for rv32imafdcv ilp32f medlow ===
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c -std=c99 -O3 -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vmv-imm-run.c -O3 -ftree-vectorize (test for excess errors)
                === g++: Unexpected fails for rv32imafdcv ilp32f medlow ===
FAIL: g++.target/riscv/rvv/base/bug-14.C (test for excess errors)
FAIL: g++.target/riscv/rvv/base/bug-9.C (test for excess errors)

These failures are not compiler's bugs, should be testcase or test framework issues.

The only issues related to compiler are these:
FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test
FAIL: gcc.target/riscv/rvv/autovec/partial/multiple_rgroup_run-2.c execution test
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/repeat_run-3.c -std=c99 -O3 -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax execution test

These 2 issues I already noticed which should be already fixed by your another patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621610.html 

Overal, this patch doesn't cause any issues.  So, we can go ahead.


Thanks.


juzhe.zhong@rivai.ai
 
From: Robin Dapp
Date: 2023-06-14 14:09
To: Li, Pan2; juzhe.zhong@rivai.ai; gcc-patches
CC: rdapp.gcc; jeffreyalaw; Wang, Yanzhang; kito.cheng
Subject: Re: [PATCH v1] RISC-V: Align the predictor style for define_insn_and_split
Hi Pan,
 
these failures were present before the patch I suppose? They
don't look related.  Is this what you meant by "the same as upstream"?
 
> FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/full-vec-move1.c -std=c99 -O3 -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for excess errors)
 
This one should probably be 64-bit only.  Would you mind adjusting it?
 
> FAIL: gcc.target/riscv/rvv/autovec/vmv-imm-run.c -O3 -ftree-vectorize (test for excess errors)
 
What's happening here?  Any details on the output?
 
I don't have a proper sim environment setup yet.  How long does the testsuite take
with spike?  Have you tried qemu as well?
 
Regards
Robin