[PATCH] D91442: [clang][Driver] Handle risvc in Baremetal.cpp.

[Hafiz Abid Qadeer via Phabricator via cfe-commits]

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