For RISC-V the value provided to -march should determine whether to compile for 32- or 64-bit RISC-V irrespective of the target provided to the Clang driver. This adds a test for this flag for RISC-V and sets the Target architecture correctly in these cases.
Rebase on top of tree.
I've noticed that without this flag calling riscv32-unknown-elf-clang -march=rv64i will still produce a rv32 binary, which is unlike GCC's behavior
What happens if I pass clang -march=rv32i -target riscv64-unknown-elf? Should we care about the ordering of -march vs -target?
Currently this patch makes the output be generated for rv32i. I think that -march should override -target since it is more fine grained, is used as the default way of controlling extensions, and may be less confusing than last XLEN wins.
The precedence seems sensible; it's what MIPS is doing for -mabi vs -target just above.
Missing a full-stop here
I have no issue with the underlying logic here.
Please rebase on top of D69383 and use riscv::getRISCVArch(...) defined in that patch rather than querying Args.getLastArg(options::OPT_march_EQ) directly.
@lenary Following the discussion regarding D69383, I think it's best for now to keep the logic just keeping -march directly, rather than using getRISCVArch. I think in the case of -target risc32-..... -mabi=lp64 I think it would confuse users if the tools suddenly changed to doing an rv64 compile. If we disable that, all that function would provide me is the same StringRef I'm already evaluating. I think adding any extra flag to indicate whether a rv32<->rv64 switch is acceptable would just make the code unnecessarily more messy. I think in the future if getRISCVArch evaluates more flags, then it might make sense to reconsider this.
Yep, I understand.
Ok, Logic and tests LGTM. I think this needs an entry in the Release Notes too.
I think the case of -target risc32-..... -mabi=lp64 is acceptable since the -target is less usable than -march/-mabi/-mcpu and is almost invisible to users.