abidh added inline comments.
================ Comment at: clang/lib/Driver/Driver.cpp:5216-5220 + if (toolchains::RISCVToolChain::hasGCCToolchain(*this, Args)) + TC = + std::make_unique<toolchains::RISCVToolChain>(*this, Target, Args); + else + TC = std::make_unique<toolchains::BareMetal>(*this, Target, Args); ---------------- jrtc27 wrote: > This has broken our use downstream. We construct a normal bare-metal > non-multilib baremetal sysroot, no GCC involved, passed explicitly with > --sysroot. However, BareMetal's findRISCVMultilibs unconditionally appends > multilib paths for anything other than IMAC (always ILP32/LP64) (well, it > still appends the path, just the multilib path is curiously empty), without > filtering out ones that don't exist like Gnu.cpp. I assume the empty string > for IMAC is a hack to allow most normal uses of bare-metal toolchains to > work, but it breaks if you want hard float support (or fewer extensions). > > I suspect this is best fixed by filtering out non-existent directories from > findRISCVMultilibs (and at the same time, fixing IMAC to have a non-empty > path, since RISCVToolChain has one for it, and we no longer need the hacky, > insufficient workaround)? IIRC the empty path was probably there to keep the non-multilib toolchain working. I don't mind if we remove the empty path for IMAC and all multilibs have non-empty paths. I am not sure on filtering out non-existing folder though. It is a bit different from GNU.cpp in that we may not be using a pre-built sysroot and use the just-built compiler for building the runtime too. Also I am wondering what should happen if user wants a multilib whose runtime bits are not present in the toolchain. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91442/new/ https://reviews.llvm.org/D91442 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
