abidh added a comment. It seems that testcase I added has brought to surface a hidden issue. If you look at the end of Generic_GCC::GCCInstallationDetector::AddDefaultGCCPrefixes, it adds sysroot/usr to the Prefixes. If the sysroot is empty, this will end up using the toolchain that you installed in /usr.
This code path is only taken if --gcc-toolchain is empty (or not given). The mips-reduced-toolchain.cpp is a good example as testcase is dependent on this behavior. If user provides a non-empty gcc-toolchain path, even if that path is non-existent, this code path is not taken. This is why riscv32-toolchain-extra.c did not fail before because it used an invalid path and not empty path for --gcc-toolchain. As a result of this behavior, if the user of RISCVToolChain does not provide a --gcc-toolchain, what happens is dependent of whether user had a riscv toolchain in /usr directory. 1. If a toolchain was present then clang will pick it 2. Otherwise clang will try clang_dir/../ (see RISCVToolChain::computeSysRoot()) For cross toolchains, this seems fragile to me. In this case, clang is picking runtime bits from a riscv64-linux-gnu for riscv32/64-unknown-elf target. This may cause difficult to debug problem. I would wait for users of RISCVToolChain to comment if this is expected behavior. If yes then I can probably update the test on the pattern of mips-reduced-toolchain.cpp. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93023/new/ https://reviews.llvm.org/D93023 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
