Recent searches
Search options
@conor I'm concerned that some ISA naming string changes (in the form consumed by -march at least) might cause issues for downstream build systems. I'm suggesting more lax parsing to try to prevent this https://reviews.llvm.org/D149246 - I'd be interested on your thoughts on e.g. If the kernel build system could be impacted: as it stands, released GCC wants z* extensions before s* (though this was fixed recently) while clang wants the opposite. Hoping to avoid a similar mess to build attributes here...
@asb I've been occasionally bitten by GCC's handling of -march strings, and yes please, when I pass a list of extensions I really want the tools to just take the union of those instructions as long as it's unambiguous and there is no opcode overlap.
The rules aren't well-specified and even people on the RISC-V tech lists don't seem to agree on all cases, such as compatibility of C with Zcmp when F/D are not implemented.
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 :)
@conor @palmer the gcc change is https://github.com/gcc-mirror/gcc/commit/4204ed2dc74390ab3689d1d6a53001761338baf6#diff-d6f7db0db31bfb339b01bec450f1b905381eb4730cc5ab2b2794971e34647d64 - it moved to z/s/x like clang HEAD (and the spec), but as this has changed multiple times now I think moving to something more permissive is the only sensible path - glad to get some external validation of that opinion. The next Clang/LLVM release won't branch until middle of the year, so there's time to sort things out before then.
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.
@conor I don't think you can as an unregistered user unfortunately