[cfe-dev] choosing the gcc toolchain

[Simon Atanasyan]

It looks like a regression after r201205. The problem is in the end of
the findMIPSMultilibs routine in the following line:

[[
else if (DebianMipsMultilibs.size() == 3) {
]]

The clang driver does not select a regular Debian MIPS toolchain if
the toolchain includes 32-bit libraries only and does not include 64
and n32 variants.

If temporarily delete FSF and CS toolchain selection it solves the
problem at least on my x86-64 Debian machines with a regular MIPS 4.7
toolchain.

[[
--- a/lib/Driver/ToolChains.cpp
+++ b/lib/Driver/ToolChains.cpp
@@ -1802,13 +1802,10 @@ bool
Generic_GCC::GCCInstallationDetector::findMIPSMultilibs(
   //  a bit of overlap in the directories that each specifies)
   if (TargetTriple.getEnvironment() == llvm::Triple::Android)
     Multilibs.combineWith(AndroidMipsMultilibs);
-  else if (DebianMipsMultilibs.size() == 3) {
+  else {
     Multilibs.combineWith(DebianMipsMultilibs);
     BiarchSibling = Multilib();
-  } else if (FSFMipsMultilibs.size() > CSMipsMultilibs.size())
-    Multilibs.combineWith(FSFMipsMultilibs);
-  else
-    Multilibs.combineWith(CSMipsMultilibs);
+  }

   llvm::Triple::ArchType TargetArch = TargetTriple.getArch();

]]

Reed, could you check this hack on the cavium board?

I will try to fix this bug.

On Fri, Feb 28, 2014 at 3:37 AM, reed kotler <rkotler at mips.com> wrote:
> The clang is working ok. I can compile, link and run a program in a simple
> fashion.
>
> I will take a look.

[...]

> On 02/27/2014 03:34 PM, Chandler Carruth wrote:
>
> My best guess is that the multilib stuff wasn't setup correctly. Note that
> MIPS has custom logic for this (findMIPSMultilibs). If that fails, then
> we'll not use the newer GCC installation. You could add logging there to try
> and figure out why.

-- 
Simon Atanasyan