On Thu, 21 Jun 2018 18:17:45 PDT (-0700), d...@redhat.com 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! _______________________________________________ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
