jrtc27 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); ---------------- abidh wrote: > 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. Well we need to detect multilib vs non-multilib sysroots *somehow*, and everywhere else that gets done based on file or directory existence. If you want a multilib but don't have it, falling back on the non-multilib path and failing (either with incompatibility errors or missing files) seems fine to me. 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
