Conversation
@asb Assuming that I cannot reply by email, I would very much be in favour of keeping the things aligned.
From a kernel PoV, we don't yet have any X stuff to worry about w/ march at the moment as the only vendor specific stuff is handballed asm (see arch/riscv/include/asm/errata_list.h).
There's no S stuff that we pass to the compiler yet either as far as a quick check reports.
Alignment with gcc is helpful, permissiveness is better?
Given "canonical order" can, and has, change(d) in the past I think it's good to insulate against it happening again.
Conjuring up march is bad enough as things stand w/ availability with given toolchain versions (I kinda hit a brick wall with rust + gcc as I don't know how to test what version of libclang bindgen is backed by).
Having to do special handing of different versions of gcc/clang whenever we do actually need to add Sfoo or Xfoo sounds like another layer of misery I would love to avoid.
Ideally one order would work for all versions of gcc and clang, but it doesn't sound like it is?
- So gcc wanted Z before X, but it now does what? Allows any order? (The
comment about "this was fixed recently" confuses me a bit, sorry)
- clang used to want Z/X/S & now wants Z/S/X? Is it too late to avoid a released clang
that uses Z/S/X rather than your suggested permissive behaviour?
Also CC @palmer :)
From a kernel PoV, we don't yet have any X stuff to worry about w/ march at the moment as the only vendor specific stuff is handballed asm (see arch/riscv/include/asm/errata_list.h).
There's no S stuff that we pass to the compiler yet either as far as a quick check reports.
Alignment with gcc is helpful, permissiveness is better?
Given "canonical order" can, and has, change(d) in the past I think it's good to insulate against it happening again.
Conjuring up march is bad enough as things stand w/ availability with given toolchain versions (I kinda hit a brick wall with rust + gcc as I don't know how to test what version of libclang bindgen is backed by).
Having to do special handing of different versions of gcc/clang whenever we do actually need to add Sfoo or Xfoo sounds like another layer of misery I would love to avoid.
Ideally one order would work for all versions of gcc and clang, but it doesn't sound like it is?
- So gcc wanted Z before X, but it now does what? Allows any order? (The
comment about "this was fixed recently" confuses me a bit, sorry)
- clang used to want Z/X/S & now wants Z/S/X? Is it too late to avoid a released clang
that uses Z/S/X rather than your suggested permissive behaviour?
Also CC @palmer :)
2
0
1
@asb @conor IMO we've made a mess of the ISA string parsing in GCC by trying to pass through all these unknown extensions. It's kind of a grey area as to whether or not they're an interface break (because upstream binutils doesn't support them), but it's certainly made for some very complicated code.
0
0
1
@asb @palmer I'll make an account for this llvm thing later & copy-pasta into that if that helps.
Permissive would be great, as hopefully we can stick to one order in the future.
Looks like we'll probably have to do some Makefile dance around older gcc/clang versions but at least going forward it should be not too bad.
Permissive would be great, as hopefully we can stick to one order in the future.
Looks like we'll probably have to do some Makefile dance around older gcc/clang versions but at least going forward it should be not too bad.
1
0
0