[Driver] Add FIXME's where we can't use effective triples (NFC)

[vsk]

Summary

... even though we *should* be able to.

If we used effective triples at the marked sites, we would fail:

• test/Driver/{darwin-dsymutil.c, darwin-debug-version.c}
  
  -ccc-print-bindings is expected to print 'x86_64-apple-darwin10', but prints 'x86_64-apple-macosx10.6.0' instead.
• test/Driver/netbsd.c
  
  We see -mcpu=arm1022e instead of arm926ej-s in a single run.
• test/Driver/linux-as.c
  
  An extra '-mfpu=neon' argument appears in a single run. Probably harmless -- the test could be relaxed.

This is part of on ongoing effort to use effective target triples
whenever we can in the clang driver (see: [cfe-dev] Lessening the
driver's reliance on default target triples).

[echristo]

Seems reasonable to fix the tests?

[dexonsmith]

I'm not sure if you're still interested in pursuing this, but...

In D22943#505523, @echristo wrote:

Seems reasonable to fix the tests?

If there are cases where this breaks (correct) tests, I think adding a FIXME is fine, but maybe it can explain in what circumstances getEffectiveTriple is currently incorrect.

lib/Driver/Driver.cpp

2274–2275

Is the test correct?

lib/Driver/Tools.cpp

8731

This refactoring looks like a nice NFC cleanup you can do regardless.

[vsk]

This isn't on my radar at the moment.

lib/Driver/Driver.cpp

     Result = InputInfo(A, BaseInput);
   else
     Result = InputInfo(A, GetNamedOutputPath(C, *JA, BaseInput, BoundArch,
                                              AtTopLevel, MultipleArchs,
                                              TC->getTriple().normalize()),
                        BaseInput);
 
   if (CCCPrintBindings && !CCGenDiagnostics) {
+    // FIXME: We should use the effective triple here, but it breaks a test
+    // on Darwin.
     llvm::errs() << "# \"" << T->getToolChain().getTripleString() << '"'
                  << " - \"" << T->getName() << "\", inputs: [";
     for (unsigned i = 0, e = InputInfos.size(); i != e; ++i) {
       llvm::errs() << InputInfos[i].getAsString();
       if (i + 1 != e)
         llvm::errs() << ", ";
     }
     llvm::errs() << "], output: " << Result.getAsString() << "\n";

lib/Driver/Tools.cpp

 void netbsd::Assembler::ConstructJob(Compilation &C, const JobAction &JA,
                                      const InputInfo &Output,
                                      const InputInfoList &Inputs,
                                      const ArgList &Args,
                                      const char *LinkingOutput) const {
   claimNoWarnArgs(Args);
   ArgStringList CmdArgs;
 
+  // FIXME: We should be able to use the effective triple here, but there is an
+  // inconsistency between the ARM target parser and the expected output.
+  const llvm::Triple &Triple = getToolChain().getTriple();
+
   // GNU as needs different flags for creating the correct output format
   // on architectures with different ABIs or optional feature sets.
-  switch (getToolChain().getArch()) {
+  switch (Triple.getArch()) {
   case llvm::Triple::x86:
     CmdArgs.push_back("--32");
     break;
   case llvm::Triple::arm:
   case llvm::Triple::armeb:
   case llvm::Triple::thumb:
   case llvm::Triple::thumbeb: {
     StringRef MArch, MCPU;
     getARMArchCPUFromArgs(Args, MArch, MCPU, /*FromAs*/ true);
-    std::string Arch =
-        arm::getARMTargetCPU(MCPU, MArch, getToolChain().getTriple());
+    std::string Arch = arm::getARMTargetCPU(MCPU, MArch, Triple);
     CmdArgs.push_back(Args.MakeArgString("-mcpu=" + Arch));
     break;
   }
 
   case llvm::Triple::mips:
   case llvm::Triple::mipsel:
   case llvm::Triple::mips64:
   case llvm::Triple::mips64el: {
     StringRef CPUName;
     StringRef ABIName;
-    mips::getMipsCPUAndABI(Args, getToolChain().getTriple(), CPUName, ABIName);
+    mips::getMipsCPUAndABI(Args, Triple, CPUName, ABIName);
 
     CmdArgs.push_back("-march");
     CmdArgs.push_back(CPUName.data());
 
     CmdArgs.push_back("-mabi");
     CmdArgs.push_back(getGnuCompatibleMipsABIName(ABIName).data());
 
-    if (getToolChain().getArch() == llvm::Triple::mips ||
-        getToolChain().getArch() == llvm::Triple::mips64)
+    if (Triple.getArch() == llvm::Triple::mips ||
+        Triple.getArch() == llvm::Triple::mips64)
       CmdArgs.push_back("-EB");
     else
       CmdArgs.push_back("-EL");
 
     AddAssemblerKPIC(getToolChain(), Args, CmdArgs);
     break;
   }
 
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel: {
     CmdArgs.push_back("-32");
-    std::string CPU = getCPUName(Args, getToolChain().getTriple());
-    CmdArgs.push_back(getSparcAsmModeForCPU(CPU, getToolChain().getTriple()));
+    std::string CPU = getCPUName(Args, Triple);
+    CmdArgs.push_back(getSparcAsmModeForCPU(CPU, Triple));
     AddAssemblerKPIC(getToolChain(), Args, CmdArgs);
     break;
   }
 
   case llvm::Triple::sparcv9: {
     CmdArgs.push_back("-64");
-    std::string CPU = getCPUName(Args, getToolChain().getTriple());
-    CmdArgs.push_back(getSparcAsmModeForCPU(CPU, getToolChain().getTriple()));
+    std::string CPU = getCPUName(Args, Triple);
+    CmdArgs.push_back(getSparcAsmModeForCPU(CPU, Triple));
     AddAssemblerKPIC(getToolChain(), Args, CmdArgs);
     break;
   }
 
   default:
     break;
   }
 

     CmdArgs.push_back(getSparcAsmModeForCPU(CPU, getToolChain().getTriple()));
     AddAssemblerKPIC(getToolChain(), Args, CmdArgs);
     break;
   }
   case llvm::Triple::arm:
   case llvm::Triple::armeb:
   case llvm::Triple::thumb:
   case llvm::Triple::thumbeb: {
+    // FIXME: We should be able to use the effective triple here, but it breaks
+    // a test for the linux assembler.
     const llvm::Triple &Triple2 = getToolChain().getTriple();
     switch (Triple2.getSubArch()) {
     case llvm::Triple::ARMSubArch_v7:
       CmdArgs.push_back("-mfpu=neon");
       break;
     case llvm::Triple::ARMSubArch_v8:
       CmdArgs.push_back("-mfpu=crypto-neon-fp-armv8");
       break;