From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpbg151.qq.com (smtpbg151.qq.com [18.169.211.239]) by sourceware.org (Postfix) with ESMTPS id 2D5D23858D20 for ; Fri, 17 Nov 2023 08:54:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2D5D23858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivai.ai Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivai.ai ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2D5D23858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=18.169.211.239 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700211261; cv=none; b=hNrpK1M+nRQt21OgkWpCKNIdOuZJGt6dvLnDi55e78p0u5z0pyODBkF2QJg5M09741Os6QO3TzOtbEIvViegTXwBx/8DUMOllPpTsmBLX89DvwvnVuo/zzuGcd1TLgaNkEECYg5Pwn6TXsF0qsNBq3Kx7XofxDpGZDSJMEmkxzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700211261; c=relaxed/simple; bh=8T8ei74iNUshQDX5Gkj5k4UgHWBlUtjQAaT7DwOhwlc=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=JmK7F2GfKJqv/Fy2DtKVs4GZ1FErBXFK18hcSAnVnocG9+DNS96PX2gA63UrHaWyOWDEy6tmP+m/5Rcln7UOimoez5Jemr1I8GUyY8PN6r2odSMRNaeMSp5X522i5KklFe2zG6JdzsOsaaQxkxeUYjsFxeOF9mE4bz34Sj1ykCc= ARC-Authentication-Results: i=1; server2.sourceware.org X-QQ-mid: bizesmtp71t1700211250tbo4yn2g Received: from [10.101.11.9] ( [113.104.249.196]) by bizesmtp.qq.com (ESMTP) with id ; Fri, 17 Nov 2023 16:54:08 +0800 (CST) X-QQ-SSF: 01400000000000C0F000000A0000000 X-QQ-FEAT: aBJFcW+uBGZEUEEfdDyHwQiyDNicp/qYtRnd3ebktTR2snM8woToBWPZvGAAU su7vdA8efth+JkxAVL32AICeclIaiTaGF6m74mV9hApsDJV+CV73Jt0fQU/CpHohVDBlnqL 1nT1NbYCGUcNyFuxpPQrgLV/ZBDRGAVSMqe1Gpr2xTL/2kBRl7MeTTzxupERk6j4pj3XkdW oEmLQqFi0psDp8xKIkm0UdPA2XRNUTm/c3kYkcaCxYlg1yz/7yafB5jgmiIL3TjhqXyObE6 VMtgQ3h78Uy9+Lw8fCrn6rEwp0MfDuoaKDbb/QRCOgOb9/0v54w3i55eDJLKRUxo7OZzNUv 8ApTkOQE20pvxcdxGXNbBuBFg83e2dhqw9MARkPVgPP22lw2rkoYXms1Oso94+JvD7qip0X 7rf6VS2I4A7qJlBIZCVw6w== X-QQ-GoodBg: 2 X-BIZMAIL-ID: 14530858236115468385 Message-ID: Date: Fri, 17 Nov 2023 16:54:09 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] RISC-V: testsuite: Fix 32-bit FAILs. Content-Language: en-US To: Kito Cheng , =?UTF-8?B?6ZKf5bGF5ZOy?= Cc: "rdapp.gcc" , gcc-patches , palmer , Jeff Law References: <811770BDC5BB922A+2023111107002540464431@rivai.ai> <0D61EBDB57E52A6A+2023111316555163240820@rivai.ai> <5bda5044-ac11-4a46-b7e7-bbf8d4890da6@gmail.com> <79df9cdb-2e5b-4e65-9c91-aae20f5c0fde@gmail.com> <2D241ED7BCDC3AB9+bae67ce6-4f85-41d6-a910-d8758e4c4b12@rivai.ai> <6ec4944f-38b4-4968-a32e-53aee94feb19@gmail.com> <4F2BF54C1D97ABBC+4118c01f-5f50-4ea5-9a21-7e6afeb86686@rivai.ai> <5e4ed623-d793-4fc1-9d32-cd8070c0444e@gmail.com> <7C790EC85A643D8D+26ecbab6-40ff-4cc7-840e-9e939e46a151@rivai.ai> <8ec62cf5-e867-4984-a1c6-e532c643c1e9@gmail.com> <84D559764B306149+f0837249-89b7-45f7-87eb-1a28636ca7da@rivai.ai> <35A570B6D16C7FF1+2023111518475899225862@rivai.ai> From: Lehua Ding In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvrgz:qybglogicsvrgz6a-0 X-Spam-Status: No, score=0.9 required=5.0 tests=BAYES_00,BODY_8BITS,FORGED_MUA_MOZILLA,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 钟居哲 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 > -- Best, Lehua (RiVAI)