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.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-14 14:09
To: Li, Pan2; juzhe.zh...@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
