Re: Re: [PATCH] RISC-V: testsuite: Fix 32-bit FAILs.

[Kito Cheng <kito.cheng@gmail.com>]

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.zhong@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.zhong@rivai.ai
>
>
> From: Lehua Ding
> Date: 2023-11-13 19:27
> To: kito.cheng; Robin Dapp
> CC: juzhe.zhong@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.zhong@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.ding@rivai.ai