Re: [PATCH] RISC-V: Add the option "-mdisable-multilib-check" to avoid multilib checks breaking the compilation.

[Jeff Law <jeffreyalaw@gmail.com>]

On 5/30/23 08:48, Maciej W. Rozycki wrote:
> 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?
Just as important, this scenario is not one that we really want to cater 
the compiler's behavior to.  We should not be introducing an unsafe 
option like this into the compiler sources -- engineers that need to do 
this kind of testing can carray this kind of patch in their downstream 
trees.

jeff