Hi Kito and Robin,
So, going back to our testcases that reported errors with this, I don't
think we should explicitly specify -march and -mabi when compiling a
runnable program, but use the defaults (--with-arch). Most of our
current runnable testcases adhere to this convention, except for the
ones we are discussing now, who are explicitly setting -march to
rv32gcv_zfh or rv64gcv_zfh inside rvv.exp file.
On 2023/11/17 16:29, Kito Cheng wrote:
Oh, ok I got why it happened and it is definitely caused by my patch
(but not that one, it is caused by another patch[1]), let me describe
the reason why I try to emit errors. RISC-V has a crazy number of
possible extension combinations, so it's easy to make some mistakes by
using some unsupported extension combination and generating error
messages that are difficult to understand.
Give some practical example here:
config a RISC-V toolchain with --with-arch=rv64gc --with-abi=lp64d
also build with multilib for rv32i/ilp32 and rv64imac/lp64
Now users try to use that toolchain with -march=rv32gc -mabi=ilp32d,
what will happen if there is no such error emitted?
GCC will fail back to default multilib which is rv64gc/lp64d, and then
you may got error message like bellow:
ABI is incompatible with that of the selected emulation:
target emulation `elf32-littleriscv' does not match `elf64-littleriscv'
Experienced toolchain developers or experienced FAE may know what happened,
but the error message is really not meaningful for most users - and
then they will go back to waste our time :P
So that's the background why I design and implement that mechnish.
You may ask: hey why not implement the same mechnish for linux?
Ok - the answer is simple - linux typically will build with
rv64gc/lp64d as base ,
No much different combination like bare metal environment.
*However* I am not trying to say: there is no solution there, let's
give up on testing with bare metal.
One possible solution is Jin Ma's patch[2], he proposed
-mdisable-multilib-check to suppress this check, but it's kind of
dangerous in most cases, this may make it compile, but will get
another error soon.
So...I think the right solution should be adding more checks before
running those tests, e.g.checking rv32gv/ilp32d can run before running
those testcase.
[1]
https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b1817876c77888f
[2] https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619234.html
On Wed, Nov 15, 2023 at 6:48 PM 钟居哲 <juzhe.zh...@rivai.ai> wrote:
Hi, Kito. Could you take a look at this issue?
-march parser is consistent between non-linux and linux.
You can simplify verify it with these cases:
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_extract-run.c -std=c99 -O3
-ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for excess
errors)
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_extract-runu.c -std=c99 -O3
-ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for excess
errors)
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_extract-zvfh-run.c -std=c99
-O3 -ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for
excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-run.c -std=c99 -O3
-ftree-vectorize --param riscv-autovec-preference=fixed-vlmax (test for excess
errors)
FAIL: gcc.target/riscv/rvv/autovec/vls-vlmax/vec_set-zvfh-run.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)
These cases failed on non-linux toolchain, but pass on linux toolchain.
This consistency is caused by your previous multilib patch as Lehua said:
https://github.com/gcc-mirror/gcc/commit/17d683d
________________________________
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-11-13 19:27
To: kito.cheng; Robin Dapp
CC: juzhe.zh...@rivai.ai; gcc-patches; palmer; jeffreyalaw
Subject: Re: [PATCH] RISC-V: testsuite: Fix 32-bit FAILs.
Hi Kito,
On 2023/11/13 19:13, Lehua Ding wrote:
Hi Robin,
On 2023/11/13 18:33, Robin Dapp wrote:
On 2023/11/13 18:22, juzhe.zh...@rivai.ai wrote:
If there is a difference between them. I think we should fix
riscv-common.cc.
Since I think "zvfh_zfh" should not be different with "zfh_zvfh"
It's possible. Let me debug it and see if there's a problem.
I don't think it is different. Just checked and it still works for me.
Could you please tell me how you invoke the testsuite?
This looks to be the difference between the linux and elf versions of
gcc. The elf version of gcc we are build will have this problem, the
linux version of gcc will not. I think the linux version of gcc has a
wrong behavior.:
➜ riscv-gnu-toolchain-push git:(tintin-dev)
./build/dev-rv32gcv_zfh_zvfh-ilp32d-medany-newlib-spike-debug/install/bin/riscv32-unknown-elf-gcc
-march=rv32gcv_zfh
build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/hello.c
riscv32-unknown-elf-gcc: fatal error: Cannot find suitable multilib set
for
'-march=rv32imafdcv_zicsr_zifencei_zfh_zfhmin_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'/'-mabi=ilp32d'
compilation terminated.
➜ riscv-gnu-toolchain-push git:(tintin-dev)
./build/dev-rv32gcv_zfh_zvfh-ilp32d-medany-linux-spike-debug/install/bin/riscv32-unknown-linux-gnu-gcc
-march=rv32gcv_zfh
build/dev-rv64gcv_zvfh_zfh-lp64d-medany-newlib-spike-debug/hello.c
It looks like this commit[1] from you make the difference between elf
and linux. Can you help to see if it makes sense to behave differently
now? elf version --with-arch is rv32gcv_zvfh_zfh, and the user will get
an error with -march=rv32gcv_zfh. linux version will not.
[1] https://github.com/gcc-mirror/gcc/commit/17d683d
--
Best,
Lehua (RiVAI)
lehua.d...@rivai.ai
--
Best,
Lehua (RiVAI)
