[clang-cl] Explicitly set object format to COFF in CL mode

[iid_iunknown]

Summary

Currently object format is taken from the default target triple. For toolchains with a non-COFF default target this may result in an object format inappropriate for pc-windows and lead to compilation issues.

For example, the default triple aarch64-linux-elf may produce something like aarch64-pc-windows-msvc19.0.24215-elf in CL mode. Clang creates MicrosoftARM64TargetInfo for such triple with data layout e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128. On the other hand, the AArch64 backend in computeDataLayout detects a non-COFF target and selects e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128 as data layout for little endian. Different layouts used by clang and the backend cause an error:

error: backend data layout 'e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128'
 does not match expected target description 'e-m:w-p:64:64-i32:32-i64:64-i128:128-n32:64-S128'

This can be observed on the clang's Driver/cl-pch.c test with AArch64 as a default target.

This patch enforces COFF in CL mode.

[hans]

Seems reasonable, but should probably have a test.

This can be observed on the clang's Driver/cl-pch.c test with AArch64 as a default target.

But why isn't that failure showing on some buildbot, then?

[iid_iunknown]

In D37336#857802, @hans wrote:

But why isn't that failure showing on some buildbot, then?

The test needs system-windows to run:

// REQUIRES: system-windows

There is no windows buildbot that builds clang defaulted to the AArch64 target.

[hans]

In D37336#857814, @iid_iunknown wrote:

In D37336#857802, @hans wrote:

But why isn't that failure showing on some buildbot, then?

The test needs system-windows to run:

// REQUIRES: system-windows

There is no windows buildbot that builds clang defaulted to the AArch64 target.

I see.

Do you think you can write a test for your patch that will work on the buildbots we have?

[iid_iunknown]

Do you think you can write a test for your patch that will work on the buildbots we have?

I am afraid, this is not possible with the existing buildbots. --target does not affect the default triple. There is LLVM_TARGET_TRIPLE_ENV that allows to override the default triple at runtime, but LLVM must be configured to support it and none of the Windows buildbots do this. I see no other way to implement such a test, unfortunately.

[hans]

lgtm

[iid_iunknown]

Thanks for reviewing this!

lib/Driver/Driver.cpp

Compilation *Driver::BuildCompilation(ArrayRef<const char *> ArgList) {
   // FIXME: DefaultTargetTriple is used by the target-prefixed calls to as/ld
   // and getToolChain is const.
   if (IsCLMode()) {
     // clang-cl targets MSVC-style Win32.
     llvm::Triple T(DefaultTargetTriple);
     T.setOS(llvm::Triple::Win32);
     T.setVendor(llvm::Triple::PC);
     T.setEnvironment(llvm::Triple::MSVC);
+    T.setObjectFormat(llvm::Triple::COFF);
     DefaultTargetTriple = T.str();
   }
   if (const Arg *A = Args.getLastArg(options::OPT_target))
     DefaultTargetTriple = A->getValue();
   if (const Arg *A = Args.getLastArg(options::OPT_ccc_install_dir))
     Dir = InstalledDir = A->getValue();
   for (const Arg *A : Args.filtered(options::OPT_B)) {
     A->claim();