[Driver] Change -dumpmachine to respect --target/LLVM_DEFAULT_TARGET_TRIPLE verbatim

[MaskRay]

Summary

This changed -dumpmachine does no normalization and follows GCC more closely
(gcc -dumpmachine on Debian may be x86_64-linux-gnu).

---

Vendors have different ideas on the canonical triple.
llvm/cmake/config.guess prefers x86_64-unknown-linux-gnu.
RedHat prefers x86_64-redhat-linux.
Suse prefers x86_64-suse-linux.
Debian/Ubuntu prefer x86_64-linux-gnu.

Traditionally they contribute their normalization rules to Triple.cpp or Clang
Driver. This is an unfortunate state: (a) less popular systems tend to patch Clang downstream
(b) Clang Driver has unneeded complexity.

To fix the unfortunate state, we should just respect
--target/LLVM_DEFAULT_TARGET_TRIPLE and do no normalization at all.
-dumpmachine can be handy when the user wants the configure-time LLVM_DEFAULT_TARGET_TRIPLE.

--print-target-triple still prints the normalized triple.
I think we probably should remove its usage in CMake compiler-rt in favor of -dumpmachine.

[hvdijk]

Does Red Hat actually use x86_64-redhat-linux with LLVM (other than for finding the GCC installation)? I didn't see this on Fedora, I think they use the config.guess-determined target name, and I think that's the right thing for them to do. That only affects whether you've got a realistic testcase though, the main change makes sense to me.

[MaskRay]

In D111367#3049700, @hvdijk wrote:

Does Red Hat actually use x86_64-redhat-linux with LLVM (other than for finding the GCC installation)? I didn't see this on Fedora, I think they use the config.guess-determined target name, and I think that's the right thing for them to do. That only affects whether you've got a realistic testcase though, the main change makes sense to me.

Thanks.

According to https://reviews.llvm.org/D110900#3041312 Red Hat GCC uses x86_64-redhat-linux.
I don't know what its Clang currently does.

[tstellar]

In D111367#3049772, @MaskRay wrote:

In D111367#3049700, @hvdijk wrote:

Does Red Hat actually use x86_64-redhat-linux with LLVM (other than for finding the GCC installation)? I didn't see this on Fedora, I think they use the config.guess-determined target name, and I think that's the right thing for them to do. That only affects whether you've got a realistic testcase though, the main change makes sense to me.

Thanks.

According to https://reviews.llvm.org/D110900#3041312 Red Hat GCC uses x86_64-redhat-linux.
I don't know what its Clang currently does.

I've been working on this for a few weeks now, and I think what I'm going to do for Red Hat clang is to use current triples generated from config.guess, but replace the unknown vendor with redhat (e.g. x86_64-redhat-linux-gnu). This will be a no-op change since llvm treats the redhat vendor as unknown, but will at least allow me to identify the triple as a redhat triple, so I can patch the clang driver to select the correct gcc install.

It seems to me it will be difficult to have one triple that both controls clang's behavior and selects the desired gcc install, because clang and gcc have different conventions. I wonder if we should have a more explicit way to select the gcc install.

[MaskRay]

In D111367#3050061, @tstellar wrote:

In D111367#3049772, @MaskRay wrote:

In D111367#3049700, @hvdijk wrote:

Does Red Hat actually use x86_64-redhat-linux with LLVM (other than for finding the GCC installation)? I didn't see this on Fedora, I think they use the config.guess-determined target name, and I think that's the right thing for them to do. That only affects whether you've got a realistic testcase though, the main change makes sense to me.

Thanks.

According to https://reviews.llvm.org/D110900#3041312 Red Hat GCC uses x86_64-redhat-linux.
I don't know what its Clang currently does.

I've been working on this for a few weeks now, and I think what I'm going to do for Red Hat clang is to use current triples generated from config.guess, but replace the unknown vendor with redhat (e.g. x86_64-redhat-linux-gnu). This will be a no-op change since llvm treats the redhat vendor as unknown, but will at least allow me to identify the triple as a redhat triple, so I can patch the clang driver to select the correct gcc install.

It seems to me it will be difficult to have one triple that both controls clang's behavior and selects the desired gcc install, because clang and gcc have different conventions. I wonder if we should have a more explicit way to select the gcc install.

If GCC installation has library files under lib/x86_64-redhat-linux, I think inferred LLVM_DEFAULT_TARGET_TRIPLE should be x86_64-redhat-linux, instead of x86_64-redhat-linux-gnu.

With correct LLVM_DEFAULT_TARGET_TRIPLE, clang a.c should just work; with incorrect LLVM_DEFAULT_TARGET_TRIPLE, it's fair for clang a.c NOT to find GCC crtbegin.o/libgcc_s.so.1/etc.

For older Clang with broken target triple, I think it is fair to ask the user to specify correct LLVM_DEFAULT_TARGET_TRIPLE (or LLVM_HOST_TRIPLE).

I hope both clang --version and clang -dumpmachine print LLVM_DEFAULT_TARGET_TRIPLE in a verbatim way.

My scheme focuses on both simplicity of clang driver (we shouldn't add more platform-specific normalization code) and porting ease for new vendors (they shouldn't need to add vendor customization code like existing suse/redhat).

[MaskRay]

If this is trivially correct, may I get a stamp?

[hvdijk]

In D111367#3050062, @MaskRay wrote:

If GCC installation has library files under lib/x86_64-redhat-linux, I think inferred LLVM_DEFAULT_TARGET_TRIPLE should be x86_64-redhat-linux, instead of x86_64-redhat-linux-gnu.

That's going to cause breakage unless @tstellar's patch to make isGNUEnvironment() return true for x86_64-redhat-linux also goes in.

With correct LLVM_DEFAULT_TARGET_TRIPLE, clang a.c should just work; with incorrect LLVM_DEFAULT_TARGET_TRIPLE, it's fair for clang a.c NOT to find GCC crtbegin.o/libgcc_s.so.1/etc.

The thing is that with Red Hat, the way I see it, it's GCC that has an incorrect triple. LLVM currently requires and gets (through config.guess) a correct triple, but accommodates for GCC's installation by still allowing its runtime files to be found. Is it really a good idea to start making LLVM get the wrong triple, and adding more customisation to treat that as if it were correct? (Edit: @tstellar's approach to make LLVM get a x86_64-redhat-linux-gnu triple avoids that problem, so that sounds good to me.)

[MaskRay]

Agree that Red Hat GCC switching to x86_64-redhat-linux-gnu is the best long-term approach.

(Edit: @tstellar's approach to make LLVM get a x86_64-redhat-linux-gnu triple avoids that problem, so that sounds good to me.)

Let the config.guess removal patch normalize x86_64-redhat-linux to x86_64-redhat-linux-gnu? That sounds good to me.
If the patch will do the normalization, I think -dumpmachine patch will be unblocked.

We will need to keep aarch64-redhat-linux GCC installation detect in clang/lib/Driver/ToolChains/Gnu.cpp for an extended period, to be buildable with older GCC still using x86_64-redhat-linux.

[MaskRay]

Abandon since we decide to try using normalized target triple and just hard code the Debian multiarch (omitted 'vendor') in few places.

clang/lib/Driver/Driver.cpp

void Driver::HandleAutocompletions(StringRef PassedFlags) const {
   llvm::outs() << llvm::join(SuggestedCompletions, "\n") << '\n';
 }
 
 bool Driver::HandleImmediateArgs(const Compilation &C) {
   // The order these options are handled in gcc is all over the place, but we
   // don't expect inconsistencies w.r.t. that to matter in practice.
 
   if (C.getArgs().hasArg(options::OPT_dumpmachine)) {
-    llvm::outs() << C.getDefaultToolChain().getTripleString() << '\n';
+    llvm::outs() << C.getDriver().getTargetTriple() << '\n';
     return false;
   }
 
   if (C.getArgs().hasArg(options::OPT_dumpversion)) {
     // Since -dumpversion is only implemented for pedantic GCC compatibility, we
     // return an answer which matches our definition of __VERSION__.
     llvm::outs() << CLANG_VERSION_STRING << "\n";
     return false;

clang/test/Driver/dumpmachine.c

+/// Test that -dumpmachine prints the triple without normalization.
+
+/// config.guess may prefer x86_64-pc-linux-gnu, but we respect --target= verbatim.
+// RUN: %clang --target=x86_64-linux-gnu -dumpmachine | FileCheck %s --check-prefix=X86_64
+// X86_64: x86_64-linux-gnu
+
+/// Note: GCC doesn't convert -dumpmachine output for multilib -m32/-mx32/-m64.
+// RUN: %clang --target=x86_64-redhat-linux -m32 -dumpmachine | FileCheck %s --check-prefix=X86_64_M32
+// X86_64_M32: i386-redhat-linux
+
+// RUN: %clang --target=xxx-pc-freebsd -dumpmachine | FileCheck %s --check-prefix=XXX
+// XXX: xxx-pc-freebsd
+
+/// Fuchsia prefers normalization.
+// RUN: %clang --target=aarch64-fuchsia -dumpmachine | FileCheck %s --check-prefix=FUCHSIA
+// FUCHSIA: aarch64-unknown-fuchsia