From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 326893858410 for ; Tue, 1 Nov 2022 18:35:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 326893858410 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pg1-x52b.google.com with SMTP id e129so14139390pgc.9 for ; Tue, 01 Nov 2022 11:35:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=EwHAZ3jmCm5IEdHvvNop/5EpR0g17CP+h5MyglYXqGI=; b=ag3DGv6v61HAN6G9Vuvd7CxiNP25gnVo4jeYNTUhVb2BNb85pFanpUXC445vnoPQGF MBkr7UOtSB4BLTMYvFONuj55JSzKAzoZv7fBbKSPCEXusc9bpABB2Qxwcuo9IOIJIrJY CCzFlaUjReooN0xr2jnTzvDkTtf9XfmNK4kWE0oOxDhO3HAd6DviVfQbgOLK9DqLaOwU VcZyxzO9nYljDx3qTNl7rz+RN8KsbWZ7QF3eYmEZZbeLwssql8guV7RtpWqpz8Y3xtYU zsZhnN2mDlkT4zIau8Gibdphqg3eZubee/HqB+SyBmCw3W5ZrukW8A6vcCSE31Urbycm LT7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EwHAZ3jmCm5IEdHvvNop/5EpR0g17CP+h5MyglYXqGI=; b=g5JFL0llWzzLCHQIfz03Ela+6QRkd5niTVmppxuhluBe2vKwXpecGYrievK0QUrKM5 FcYrfp3D9EYiEakxF3tA4gkDwX41gZ71aRBRshoEmFuclUolJ6GbADLMdPwUE7KxFwCN 80+HeY+oeTFdeGW47/jMhp7Y/pMCE4gQfqHeyGNp8HOsQcBItTb1/YZpKxWyjRQ4koi/ D/f4aljDFX1+6FmSEvGWYgCnqhwRA7naeq0Io+EsUw8cP5QtZUYbgDxWs2EuUtqOj01s hV0U+/PwtDTwIbtPZwgAUlOJM2ujMokaPENjJKqVFAPdH31xuL0ixl+33k/ZU8y+v6Bs EAkQ== X-Gm-Message-State: ACrzQf1kqyOgz8ugZ2FmwZTEw5F+ATu8MV7fxvdmtGu4HLN+rJYj4J5p E29vZsZdKnlnYtq6rX/k6f/vaUXVT2ylJQ== X-Google-Smtp-Source: AMsMyM4YRuYA011jfbRTUR2/1hvwtUycBXiAJt2eTTedWKc5mEHlbDcKPCZw4kgdm47amlwHgrpEEg== X-Received: by 2002:a63:187:0:b0:43b:cf3c:c64d with SMTP id 129-20020a630187000000b0043bcf3cc64dmr17966258pgb.359.1667327701369; Tue, 01 Nov 2022 11:35:01 -0700 (PDT) Received: from localhost ([50.221.140.188]) by smtp.gmail.com with ESMTPSA id s20-20020a63d054000000b0046f73d92ea5sm6114186pgi.90.2022.11.01.11.35.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Nov 2022 11:35:00 -0700 (PDT) Date: Tue, 01 Nov 2022 11:35:00 -0700 (PDT) X-Google-Original-Date: Tue, 01 Nov 2022 11:35:02 PDT (-0700) Subject: Re: Re: [PATCH] RISC-V: Fix RVV testcases. In-Reply-To: CC: gcc-patches@gcc.gnu.org, schwab@linux-m68k.org, gcc-patches@gcc.gnu.org, Kito Cheng From: Palmer Dabbelt To: juzhe.zhong@rivai.ai Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 31 Oct 2022 16:52:25 PDT (-0700), juzhe.zhong@rivai.ai wrote: > These cases actually doesn't care about -mabi, they just need 'v' in -march. > Can you tell me how to fix these testcases for "fails on targets without ilp32d" ? > These failures are bogus failures since if you specify -mabi=ilp32d when you are using GNU toolchain which is build up with "--arch=ilp32" let say. > It will fail. Report there is no "ilp32d". So I fix these testcase by replacing "ilp32d" into "ilp32". So the problem is this just moves the failures around, rather than failing on toolchains that lack ilp32d support it'll fail on toolchains that lack ilp32 support. The ABI naming scheme sort of makes them look like extensions, but they're just incompatible with each other. I can see a handful of ways to fix this: * Add some sort of automatic ABI scheme to GCC. LLVM already does this and there was a GCC patch for it that had some issues, but IMO having something like -mabi=auto-{min,max} would be useful as users keep running into this problem. We could also add something to DejaGNU that does this. * Add some sort of -march=+v to GCC, along the lines of the .option arch,+v stuff in assembly but from the command line. I seem to remember proposals for that floating around somewhere, but can't find anything. This could probably also to DejaGNU. * Decorate all these V functions with the +arch attributes. That wouldn't require any compiler changes, but it's kind of clunky. * Add some sort of test suite logic (maybe in DejaGNU?) to check and see if the desired ABI is linkable before attempting to do so. That might be generically useful. > Thank you. > > > > juzhe.zhong@rivai.ai > > From: Palmer Dabbelt > Date: 2022-11-01 06:30 > To: gcc-patches > CC: juzhe.zhong; gcc-patches; schwab; Kito Cheng > Subject: Re: [PATCH] RISC-V: Fix RVV testcases. > On Mon, 31 Oct 2022 15:00:49 PDT (-0700), gcc-patches@gcc.gnu.org wrote: >> >> On 10/30/22 19:40, juzhe.zhong@rivai.ai wrote: >>> From: Ju-Zhe Zhong >>> >>> gcc/testsuite/ChangeLog: >>> >>> * gcc.target/riscv/rvv/base/abi-2.c: Change ilp32d to ilp32. >>> * gcc.target/riscv/rvv/base/abi-3.c: Ditto. >>> * gcc.target/riscv/rvv/base/abi-4.c: Ditto. >>> * gcc.target/riscv/rvv/base/abi-5.c: Ditto. >>> * gcc.target/riscv/rvv/base/abi-6.c: Ditto. >>> * gcc.target/riscv/rvv/base/abi-7.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-1.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-10.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-11.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-12.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-13.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-2.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-3.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-4.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-5.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-6.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-7.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-8.c: Ditto. >>> * gcc.target/riscv/rvv/base/mov-9.c: Ditto. >>> * gcc.target/riscv/rvv/base/pragma-1.c: Ditto. >>> * gcc.target/riscv/rvv/base/user-1.c: Ditto. >>> * gcc.target/riscv/rvv/base/user-2.c: Ditto. >>> * gcc.target/riscv/rvv/base/user-3.c: Ditto. >>> * gcc.target/riscv/rvv/base/user-4.c: Ditto. >>> * gcc.target/riscv/rvv/base/user-5.c: Ditto. >>> * gcc.target/riscv/rvv/base/user-6.c: Ditto. >>> * gcc.target/riscv/rvv/base/vsetvl-1.c: Ditto. >> >> I'm pretty new to the RISC-V world, but don't some of the cases >> (particularly the abi-* tests) verify that the ABI specification does >> not override the arch specification WRT availability of types? > > I think that depends on what the ABI specification says here, as it > could really go many ways. Most of the RISC-V targets just use -mabi to > control how arguments end up passed in functions, not the availability > of types. I can't find the ABI spec for these, though, so I'm not > entirely sure how they're supposed to work... > > That said, I'm not sure why we need any of these -mabi changes? Just > from spot checking some of the examples it doesn't look like there > should be any functional difference between ilp32 and ilp32d here: > -march is always specified so ilp32d looks valid. If this is just to > fix the "fails on targets without ilp32d" [1], then IMO it's not really > a fix: we're essentially just changing that to "fails on targets without > ilp32", we either need some sort of automatic march/mabi setting or a > dependency on the availiable multilibs. Some of these can probably > avoid linking, but we'll have execution tests at some point. > > 1: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604644.html >