[asb]

You could certainly change the default `-march` to rv64g (plus whatever extensions you want) rather than rv64gc. That provides mostly what you'd want, though there's some small chance that inline asm or hand-written assembly using `.option rvc` or `.option arch, +c` inappropriately causes issues. I just posted some thoughts on this here: https://lists.riscv.org/g/tech-profiles/message/348

[rwmj]

Using 'clang -march=rv64g' does work but it's a pain in the neck for Linux distros. [Edit] The question is, is there a way to change this at llvm build time? I wasn't able to find a way. For GNU binutils it is relatively simple.

BTW I've been writing a document on the topic of how Linux distros will support hardware with and without compressed: https://github.com/rwmjones/rhrq-riscv-extensions/blob/main/...

[asb]

99.9% of my clang invocations are from the build dir of the git tree I'm working on, so I could be missing something known to others on the distribution side - but let me try my best answer.

Firstly, as you probably know the Clang/LLVM model is quite different to gcc/binutils in terms of build-time configuration. Any clang can target any architecture (unless it was disabled at build time) using --target=$TRIPLE (see <https://clang.llvm.org/docs/CrossCompilation.html#target-tri...>). In practice it's not as useful as it sounds of course because you need appropriate sysroots. You can control the default with LLVM_DEFAULT_TARGET_TRIPLE, but without patching clang it's going to enabled compressed for the riscv64-unknown-linux-gnu triple. I think the standard way of controlling other default flags would be to deploy a configuration file <https://clang.llvm.org/docs/UsersManual.html#configuration-f...> - though I'd need to check which logic took precedent if you explicitly passed --target=riscv64-unknown-linux-gnu. Ultimately we'd need to change the meaning of the current linux triples, or decide upon new ones I think.

Thanks for sharing that doc - really helpful. I don't know if it's different with GNU as, but not that if a file contains `.option rvc` that _isn't_ sufficient to set the EF_RISCV_RVC ELF flag with LLVM. Additionally, I'd imagine in general that people using .option in inline asm may see different behaviour for Clang vs GCC. Clang doesn't generate assembly output that then gets passed to the assembly - ELF emission happens directly (of course, with the assembler being invoked as needed for inline asm blocks), and so it's rather difficult to replicate the effect you'd see with GCC generating a .s file that's then assembled.