From: "Maciej W. Rozycki" <macro@embecosm.com>
To: Jin Ma <jinma@linux.alibaba.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>,
"kito.cheng" <kito.cheng@gmail.com>,
jeffreyalaw <jeffreyalaw@gmail.com>,
"richard.sandiford" <richard.sandiford@arm.com>,
"christoph.muellner" <christoph.muellner@vrull.eu>,
"jinma.contrib" <jinma.contrib@gmail.com>
Subject: Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.
Date: Tue, 30 May 2023 15:48:55 +0100 (BST) [thread overview]
Message-ID: <alpine.DEB.2.20.2305301539550.28892@tpp.orcam.me.uk> (raw)
In-Reply-To: <d982aad4-8b33-4882-a6a5-6aa56e7bed98.jinma@linux.alibaba.com>
On Mon, 29 May 2023, Jin Ma wrote:
> > 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 =lp64d --with-arch =rv64imafdc_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=lp64d -march=rv64imafdc" for
> the compilation of a specific .c file in the program, which will cause the link to
> fail and throw the following error: "FATAL ERROR: Can't find suitable multilib set for
> '-march=rv64imafdc'/'-mabi=lp64d'". This does not satisfy the purpose of the test.
Thank you. This is weird and contrary to how things used to work since
forever (not necessarily an argument by itself, but our usual arrangement
seemed reasonable). So whenever `--disable-multilib' has been used for
GCC configuration I would expect all the multilib logic to be suppressed
(as it used to be) and all assembler output just being thrown at the
linker hoping for the best (the linker has its own logic to decide what's
compatible enough and what's not; modulo any bugs of course).
So has the change in semantics actually been intentional?
Maciej
next prev parent reply other threads:[~2023-05-30 14:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-23 4:42 Jin Ma
2023-05-25 16:10 ` Kito Cheng
2023-05-26 13:19 ` Maciej W. Rozycki
2023-05-29 2:53 ` Jin Ma
2023-05-29 3:14 ` Kito Cheng
2023-05-29 3:46 ` Jin Ma
2023-05-29 13:02 ` Jeff Law
2023-05-30 14:48 ` Maciej W. Rozycki [this message]
2023-05-30 23:39 ` Jeff Law
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.20.2305301539550.28892@tpp.orcam.me.uk \
--to=macro@embecosm.com \
--cc=christoph.muellner@vrull.eu \
--cc=gcc-patches@gcc.gnu.org \
--cc=jeffreyalaw@gmail.com \
--cc=jinma.contrib@gmail.com \
--cc=jinma@linux.alibaba.com \
--cc=kito.cheng@gmail.com \
--cc=richard.sandiford@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).