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

[Palmer Dabbelt]

On Thu, 21 Jun 2018 18:17:45 PDT (-0700), address@hidden wrote:
> 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.

Yes, that's what I meant.

> 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.

That's why I was worried it's a bit odd.  Sounds like we should just leave the 
config.guess patch out, then.  That means "riscv-*" will always be "riscv32-*", 
which seems like a reasonable policy -- it matches 

> 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.

That's an orthogonal axis of naming here.  As far as I understand it we've 
always supported names like "riscv32-gcc", the questions here are:

* Should we support "riscv-gcc".  We're saying yes to this, and that it'll mean 
 the same as "riscv32-gcc".  On a 64-bit native system the compiler will be 
 called "riscv64-*", while on a 32-bit system it can be called either 
 "riscv-*" or "riscv32-*".  Cross compilers don't have a native system, so 
 they can call the toolchain "riscv-*", "riscv32-*", or "riscv64-*".
* Should we force "riscv-gcc" to require "-march" (and by extension also 
 "-mabi") if it's a cross compiler.  There seem to be sane arguments for this, 
 but it's not really a config.{guess,sub} issue so we're punting on it for now.
* Should we change to "riscv32i-*", "riscv32e-*", and "riscv64i-*"?  I'm not 
 opposed to this as an idea, but I don't think it's worth breaking backwards 
 compatibility over.  I'd be OK adding these, but not removing "riscv32-*" and 
 "riscv64-*".  I'm ready to be done discussing this, but if someone submits a 
 patch then it's OK with me :).
* Should we support "riscv32imafdc-gcc".  We're saying no to this, as it just 
 seems like that path would quickly lead to insanity.  We've got multilib 
 support for this use case anyway.

If I understand everything correctly my original patch matches this behavior, 
and everyone who's commented so far is fine with the behavior.

Thanks!