From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) by sourceware.org (Postfix) with ESMTPS id 9A13F3857729 for ; Mon, 29 May 2023 03:14:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9A13F3857729 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ua1-x935.google.com with SMTP id a1e0cc1a2514c-784e2b8c1d7so713712241.0 for ; Sun, 28 May 2023 20:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685330075; x=1687922075; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=s4T5dztYbiJHjFusX1Z1j45Hr4Hua8lO+lpDiZL27Bk=; b=PKhp8IKi+exqhh41sXTBAUg5KtrpBWSlxZWtE1VR1mBUsBd/JBEBEFZt/KBYuGpuwG Ua83F5mP52gg2rGERVI0y55pka228CqlPCdIVzWZscQybSCwFwRrimVOAwNiaBoUZs6r ZOEqrg9nWKBTbIq3JLeGzBVuOaH9dffEBSJalT14pSef1/PS2IFToYuXbdgstqwTFRlB wD+PyQGfem4hUMrySDnAyJZtDhGruyiKh/0mnPiarwDby4isNdoeX88MJfdmmvOFkar2 Xb/bD9ilGjLHXXdm6k7IdAc+oOdGPCFmVY7+bLoWLv6xXxI2KzIWYDppMaRvcNQiAO9R OKfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685330075; x=1687922075; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=s4T5dztYbiJHjFusX1Z1j45Hr4Hua8lO+lpDiZL27Bk=; b=Bb0vzlv0yaYy8MYES7TeKqDJgNhr25GtwGLYSM1jWkOaxIznuMocwr70lKqImVaa8l du8qpvd9Xr6ge89TE7Gs6NA/8IIAoSQy1mLm5prMvK6suGmZ/ID6+ns4gzwOJ4dljqji hC7jWyPp4eDmJsGi2+U5ZqDRHU9Oiu2IsYYEyCL1z1P+FY1m4lcbBxbAO/EQ+5aT5a0Y aChERjFU7dotQ286oXUxx037MkaWEZTO2K67eqJ6VJOi1ai8Der0jR4/nRjTJtg5KEp8 mX2ClZKqtJLfqHhEm+iyXwdgnzGL9+jrJzLjmJ6GVa/uHAG80uLQ3xUWWCeE/RNsLARO AJKw== X-Gm-Message-State: AC+VfDwN1A2Ya1SY/U6uZSxw8x68zA2wc5PuLrkUeWqMa9ps58h1JLNn 91+Yh/YY4gn+nhk6Opt55KKAa49vfVjyFw7+lo0= X-Google-Smtp-Source: ACHHUZ6FVF8UA1AiJg6AMITMCz/wbzD1ftdDMlyXwb8MrBmAOdfiUukElGV4nVrubGf369+SjsniSiCtxSk+CwaPD/k= X-Received: by 2002:a1f:d085:0:b0:43f:c8ee:62e9 with SMTP id h127-20020a1fd085000000b0043fc8ee62e9mr1826665vkg.15.1685330074776; Sun, 28 May 2023 20:14:34 -0700 (PDT) MIME-Version: 1.0 References: <20230523044202.1201-1-jinma@linux.alibaba.com> In-Reply-To: From: Kito Cheng Date: Mon, 29 May 2023 11:14:23 +0800 Message-ID: Subject: Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation. To: Jin Ma Cc: gcc-patches , "Maciej W. Rozycki" , jeffreyalaw , "richard.sandiford" , "christoph.muellner" , "jinma.contrib" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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, May 29, 2023 at 10:53=E2=80=AFAM Jin Ma w= rote: > > > > When testing a extension, it is often necessary for a certain program= not to > > > need some kind of extension, such as the bitmanip extension, to evalu= ate the > > > performance or codesize of the extension. However, the current multil= ib rules > > > will report an error when it is not a superset of the MULTILIB_REQUIR= ED list, > > > which will cause the program to be unable to link normally, thus fail= ing to > > > achieve the expected purpose. > > > > Hmm, I have troubles understanding what is going on here. What do you > > refer to by saying: "it is not a superset of the MULTILIB_REQUIRED list= "? > > This is a new matching rule added by kito for the multilib of riscv: > https://github.com/gcc-mirror/gcc/commit/d72ca12b846a9f5c01674b280b181787= 6c77888f > > > There should be no problem with linking compiled modules together that > > make use of different extensions, with the static linker figuring out t= he > > combined set of extensions actually required at run time for the progra= m > > loader to consider, as long as the modules do not have contradicting > > requirements, e.g. big vs little endianness or RV32 vs RV64. > > > > Can you give me a specific example (compilation options and multilibs > > available) of a failure you refer to? > > A simple example: > 1. Use "--disable-multilib --with-abi =3Dlp64d --with-arch =3Drv64imafdc_= zba_zbb_zbc_zbs" > to build the toolchain". > 2. Use the toolchain to test the impact of zba_zbb_zbc_zbs extensions on = the > performance and codesize of some functions or files in the program. > > In this case, I may need to use the command "-mabi=3Dlp64d -march=3Drv64i= mafdc" for > the compilation of a specific .c file in the program, which will cause th= e link to > fail and throw the following error: "FATAL ERROR: Can't find suitable mul= tilib set for > '-march=3Drv64imafdc'/'-mabi=3Dlp64d'". This does not satisfy the purpose= of the test. I feel this case should be build with --with-arch =3Drv64imafdc and test with -march=3Drv64imafdc and -march=3Drv64imafdc_zba_zbb_zbc_zbs, but anyway I am OK with option :P > > I think this needs an option to turn off this check. Users sometimes, jus= t as > gcc uses the default multilib when it does not match the appropriate mult= ilib, > do not need the `security lock`, and should already understand the risks > of using this option. > > > Is this something that could be solved without resorting to a possibly > > dangerous hack, by making use of MULTILIB_REUSE? > > Regarding the use of MULTILIB_REUSE, I think kito's patch has already bee= n explained > and is currently implemented according to the new rules. > https://github.com/gcc-mirror/gcc/commit/5ca9980fc86242505ffdaaf62bca1fd5= db26550b > > > > > Maciej > > Thanks, > Jin