config-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add "riscv" as an alias for "riscv32"


From: Manuel A. Fernandez Montecelo
Subject: Re: [PATCH] Add "riscv" as an alias for "riscv32"
Date: Fri, 22 Jun 2018 12:39:20 +0200

2018-06-22 3:17 GMT+02:00 DJ Delorie <address@hidden>:
>
> If by this patch you mean that "riscv-unknown-linux-gnu" means EITHER
> riscv32 (when on a 32-bit os) OR riscv64 (when on a 64-bit os), then I
> would prefer *against* this, as it would mean that config.guess would
> return an ambigious value - there is no version of GNU/Linux that
> supports both riscv32 and riscv64 at the same time.
>
> Keeping the 32/64 suffix is consistent with the s390/s390x case right
> below it, where s390 is 31-bit and s390x is 63-bit, rather than having
> one name mean "either".
>
> We also don't combine x86_64 and i*86, and *one* chips supports both of
> those.
>
> I have no problem with users selecting riscv-* explicitly, or toolchains
> shortening prefixes.  TPF does this (resulting programs are like
> tpf-gcc, not tpf-something-else-gcc) for example.  But that shouldn't be
> config.guess's job.  Config.guess is used for more than the toolchain's
> default program name.

Thanks for articulating this so well.

I have the same opinion, adding ambiguity will cause more problems
than benefits.

Besides, in Debian we even have a tendency to do the other way around
and be more explicit, for example substituting calls from "gcc" to the
explicit riscv64-linux-gnu-gcc or other targets, and it helps quite a
lot in some cross-compilation situations.

If I understand this correctly, this change would probably make things
more difficult when compiting for riscv32 from a riscv64 system.


Cheers.
-- 
Manuel A. Fernandez Montecelo <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]