DJ's and Karsten's concerns match my config-for-target vs
config-for-toolchain distinction.
arm*- riscv-* and x86-* do make sense as compiler prefixes that indicate
toolchain support for a set of targets. But when we think of a toolchain
+ a set of standard libraries (without multilib), only a single target
makes sense, so those 3 are all bad.
On the other hand riscv32 is bad because, as I just learned, there are
*3* base ISAs, not *2*, and riscv32e and riscv32i are totally
incompatible. So for targets we need riscv32e-* riscv32i-* riscv64e-*.
riscv{32,64} may be what uname does, but uname's output is the most
harmful of here: it's too vague for actual targets, and too specific for
stdlib-less embedded compiler prefixes, so both camps are left wanting.
As to riscv-* I see the exact-target and toolchain use-cases as
fundamentally irreconcilable, so GNU config should just learn the
difference so as to satisfy everyone *without* compromise. If we can
agree on this I volunteer to immediately do all the work---I now have
enough information from this thread.
And finally, the original patch is no good in my mind even as a first
incremental step, as the unconditional riscv- to riscv32- desugar is
also wrong for embedded and desktop/distro alike.
John
P.S. Sorry to be basically repeating myself, but I think I was too wordy
the first time / lost within the fast pace of the thread the first time
around
_______________________________________________
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
