lenary added a comment.
In D67508#1720228 <https://reviews.llvm.org/D67508#1720228>, @khchen wrote: > But there is some issue if we set the default rv32 march as `rv32gc`. > Because the default multilib does not include `rv32gc`/`lp32d` in riscv gnu > toolchain, > https://github.com/riscv/riscv-gcc/blob/ed3f6ec/gcc/config/riscv/t-elf-multilib#L19 > so if user does not give the default march clang will not find the library > and cause linking error. > Do you think this is a clang's problem? or maybe this is just user's problem > so they should config multilib to support `rv32gc/lip3d2d`? Oh, I'm seeing how these pieces (don't) fit together now. Sorry for missing that the defaults in D69383 <https://reviews.llvm.org/D69383> don't quite line up with this patch. ~~What happens if a user requests a `t-multilib-elf` build of GCC, without specifying `--with-arch=` or `--with-abi=`, then they get a default march/mabi combination that they don't have a multilib for, or do the definitions come from somewhere else?~~ So I realise that the `--with-arch=` and `--with-abi=` options come from `t-elf-multilib` when gcc is built. Looking closer at the `t-elf-multilib` file, there's not any `ilp32d` configuration, which seems like an oversight if people want to use that ABI on elf targets. So, I guess there are three choices: 1. We change the defaults in `D69383` to match the elf multilibs that are built today. (i.e., one of the current multilib choices will become a default). 2. We request a change in the `t-elf-multilib` `MULTILIB_REQUIRED` list to add `rv32imafdc`/`ilp32d` (and add an `rv32gc`/`ilp32d` alias to `MULTILIB_REUSE`) (This probably requires rebuilding existing multilib configurations, to compile this extra combination) 3. We request a change in `config.gcc` (and I update my patch to reflect it) (This probably means having per-target defaults for linux vs elf, and ensuring these defaults are in the multilib file). Part of the issue is it's not great to change defaults (we can probably only do it for clang 10, and never again), and it's not great to make people recompile their gcc toolchains either. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D67508/new/ https://reviews.llvm.org/D67508 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
