This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RISC-V ELF multilibs
- From: Jim Wilson <jimw at sifive dot com>
- To: Sebastian Huber <sebastian dot huber at embedded-brains dot de>, GCC <gcc at gcc dot gnu dot org>
- Cc: Palmer Dabbelt <palmer at dabbelt dot com>
- Date: Tue, 29 May 2018 11:02:58 -0700
- Subject: Re: RISC-V ELF multilibs
- References: <233244769.189066.1527339877501.JavaMail.zimbra@embedded-brains.de>
On 05/26/2018 06:04 AM, Sebastian Huber wrote:
Why is the default multilib and a variant identical?
This is supposed to be a single multilib, with two names. We use
MULTILIB_REUSE to map the two names to a single multilib.
rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc
./rv64imafdc/lp64d/libgcc.a
rohan:1031$ ./xgcc -B./ -march=rv64gc -mabi=lp64d --print-libgcc
./rv64imafdc/lp64d/libgcc.a
rohan:1032$ ./xgcc -B./ --print-libgcc
./libgcc.a
rohan:1033$
So this is working right when the -march option is given, but not when
no -march is given. I'd suggest a bug report so I can track this, if
you haven't already filed one.
Most variants include the C extension. Would it be possible to add -march=rv32g and -march=rv64g variants?
The expectation is that most implementations will include the C
extension. It reduces code size, improves performance, and I think I
read somewhere that it takes only 400 gates to implement.
It isn't practical to try to support every possible combination of
architecture and ABI here, as there are too many possible combinations.
But if there is a major RISC-V target that is rv32g or rv64g then we
should consider it. You can of course define your own set of multilibs.
Jim