Write a primary version for that, did you mind giving it a try?
The basic idea is to select multilib only by ABI, so that we don't
need to bother with endless multilib reuse cases...
On Wed, Apr 19, 2023 at 9:38 AM Kito Cheng wrote:
>
> OK, thanks, I know what the problem is, I tried rv64 but
OK, thanks, I know what the problem is, I tried rv64 but didn't try
rv32, I have another fix in my mind, and will post another fix soon.
On Wed, Apr 19, 2023 at 9:29 AM Palmer Dabbelt wrote:
>
> On Tue, 18 Apr 2023 18:26:18 PDT (-0700), Kito Cheng wrote:
> > And which -march -mabi you used will
On Tue, 18 Apr 2023 18:26:18 PDT (-0700), Kito Cheng wrote:
And which -march -mabi you used will got issue?
On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt wrote:
On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote:
> Do you mind shared gcc configure and the option you tried?
Just
And which -march -mabi you used will got issue?
On Wed, Apr 19, 2023 at 8:51 AM Palmer Dabbelt wrote:
>
> On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote:
> > Do you mind shared gcc configure and the option you tried?
>
> Just riscv-gnu-toolchain with "--enbale-multilib
On Tue, 18 Apr 2023 17:47:31 PDT (-0700), Kito Cheng wrote:
Do you mind shared gcc configure and the option you tried?
Just riscv-gnu-toolchain with "--enbale-multilib --enable-linux".
On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote:
On Tue, 18 Apr 2023 08:44:24 PDT (-0700),
Do you mind shared gcc configure and the option you tried?
On Wed, Apr 19, 2023 at 4:01 AM Palmer Dabbelt wrote:
>
> On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> >> Yep, if I drop the non-canonicial strings via
> >>
> >> diff --git
On Tue, 18 Apr 2023 08:44:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
Yep, if I drop the non-canonicial strings via
diff --git a/gcc/config/riscv/multilib-generator
b/gcc/config/riscv/multilib-generator
index 58b7198b243..a63a4d69c18 100755
---
> Yep, if I drop the non-canonicial strings via
>
> diff --git a/gcc/config/riscv/multilib-generator
> b/gcc/config/riscv/multilib-generator
> index 58b7198b243..a63a4d69c18 100755
> --- a/gcc/config/riscv/multilib-generator
> +++ b/gcc/config/riscv/multilib-generator
> @@
On Mon, 17 Apr 2023 08:24:44 PDT (-0700), Palmer Dabbelt wrote:
> On Fri, 14 Apr 2023 00:15:07 PDT (-0700), Kito Cheng wrote:
>> Wait, take second round review:
>>
>>> * All extensions were being prefixed with an underscore, which leads to
>>> some odd combinations like "rv32gc_v", this just
On Fri, 14 Apr 2023 00:15:07 PDT (-0700), Kito Cheng wrote:
Wait, take second round review:
* All extensions were being prefixed with an underscore, which leads to
some odd combinations like "rv32gc_v", this just adds underscores to
the multi-letter extensions.
* The input base ISAs were
Wait, take second round review:
> * All extensions were being prefixed with an underscore, which leads to
> some odd combinations like "rv32gc_v", this just adds underscores to
> the multi-letter extensions.
> * The input base ISAs were being canonicalized, which resulted in some
> odd
Thanks for catch this, I didn't enable multilib for linux toolchain
for a while,
I guess we should implement TARGET_COMPUTE_MULTILIB for linux targets
to simplify the damm multilib files, but I agree it's too late in the
release cycle, so let's fix that in this way for now.
So LGTM and OK for
It looks like multilib-generator hasn't been run for t-linux-multilib in
a while and it's pretty broken. In order to regenerate the stub with
support for V I needed a pair of fixes:
* All extensions were being prefixed with an underscore, which leads to
some odd combinations like "rv32gc_v",
13 matches
Mail list logo
