[clang] [MinGW] Add the option -fno-auto-import

[mstorsjo]

Summary

In GCC, the .refptr stubs are only generated for x86_64, and only
for code models medium and larger (and medium is the default for
x86_64 since this was introduced). They can be omitted for
projects that are conscious about performance and size, and don't
need automatically importing dll data members, by passing -mcmodel=small.

In Clang/LLVM, such .refptr stubs are generated for any potentially
symbol reference that might end up autoimported. The .refptr stubs
are emitted for three separate reasons:

• Without .refptr stubs, undefined symbols are mostly referenced with 32 bit wide relocations. If the symbol ends up autoimported from a different DLL, a 32 bit relative offset might not be enough to reference data in a different DLL, depending on runtime loader layout.
• Without .refptr stubs, the runtime pseudo relocation mechanism will need to temporarily make sections read-write-executable if there are such relocations in the text section
• On ARM and AArch64, the immediate addressing encoded into instructions isn't in the form of a plain 32 bit relative offset, but is expressed with various bits scattered throughout two instructions - the mingw runtime pseudo relocation mechanism doesn't support updating offsets in that form.

If autoimporting is known not to be needed, the user can now
compile with -fno-auto-import, avoiding the extra overhead of
the .refptr stubs.

However, omitting them is potentially fragile as the code
might still rely on automatically importing some symbol without
the developer knowing. If this happens, linking still usually
will succeed, but users may encounter issues at runtime.

Therefore, if the new option -fno-auto-import is passed to the compiler
when driving linking, it passes the flag --disable-auto-import to
the linker, making sure that no symbols actually are autoimported
when the generated code doesn't expect it.

[rnk]

I'm a little concerned about overloading the code model this way. Currently we have the levels tiny, small, medium, large. Default is the same as small in every way so far as I'm aware. On COFF, the code models are currently untested, so far as I know, and I've been assuming that any usage of the non-small code model more or less implies ELF, and that it would be reasonable to emit wrong code or a fatal error on such codepaths during LLVM codegen. Maybe we have some use cases for the other code models in MCJIT.

With this change, "default" is now a new level that implies not small, but not medium either. Basically, I'm concerned that if we add this feature under -mcode-model=small, users will play with -mcode-model=medium, and they'll run into LLVM backend fatal errors, crashes, or wrong code. So, before we do this, I'd like to do some testing of COFF with the other code models, and make sure that LLVM does something reasonable in the other models, before we encourage users to use this flag.

[mstorsjo]

Fair enough.

On GCC, where the mingw x86_64 default code model is medium, switching it to small gave a small but not insignificant save in code size (around 9KB on a 1,3 MB DLL). On clang, where the default code model is small, getting rid of the extra refptrs didn't gain more than around 512 bytes on the same DLL. So I think it's fair to say this change isn't really important, especially not with the iffy handling of code model that it requires.

[rnk]

Well, I'm curious what meaning GCC ascribes to a medium code model for COFF. Do they generate code to allow PE images larger than 2GB, or is it more like the ELF small code model, where they assume everything can be reached with RIP relative addressing?

[mstorsjo]

In D61670#1495535, @rnk wrote:

Well, I'm curious what meaning GCC ascribes to a medium code model for COFF. Do they generate code to allow PE images larger than 2GB, or is it more like the ELF small code model, where they assume everything can be reached with RIP relative addressing?

Not entirely sure TBH (and browsing GCC code to find out isn't the easiest thing). The strange thing is that when outputting assembly with -S, gcc produces the exact same thing regardless of the -mcmodel parameter, even if the emitted object file is vastly different.

[alexhenrie]

Any update on this? The Wine project would like to omit the refptr symbols, see https://gitlab.winehq.org/wine/wine/-/merge_requests/3109

[mstorsjo]

I'm looking to pick this up again - hopefully @rnk has time to discuss what would be a good way forward.

So taking it from the top; both GCC and Clang generate .refptr stubs when referencing variables that might be autoimported. The exact circumstances differ a little bit though.

In GCC this is done by making GCC for Windows/x86_64 default to a medium code model, and under this code model, references to variables without a visible definition get indirection via a .refptr stub. This doesn't happen for i386. By building with -mcmodel=small, one can opt out of them.

In Clang, we generate such .refptr stubs with similar heuristics (variables without a visible definition), but we do it for all architectures. There are three different reasons for wanting to do this:

• Normally, when code references a variable (in the default code model), it is done with a 32 bit relative (or absolute) relocation. If the variable turns out to end up imported from a different DLL, in a 64 bit address space it may end up loaded too far away for a 32 bit relocation.
• If we don't use a .refptr stub, the mingw runtime pseudo relocation mechanism needs to patch the address at runtime. If this is referenced in a code section, it means that the code section needs to be mapped RWX while patching it. Changing the memory protection to RWX is generally undesireable (and is disallowed outright, within the UWP app model).
• The runtime pseudo relocation format works on N-bit relative or absolute addresses. With the x86 instruction encoding, this turns out to work fine - an instruction that refers to a different memory location generally is a couple bytes of instruction prefix, followed by a 32 bit relative or absolute address, easily patchable. In the case of ARM and AArch64, there are no such instructions, and loading e.g. a 32 bit immediate constant is often done by a pair of instructions, with the actual payload bits scattered throughout the instructions. The runtime pseudo relocation format obviously doesn't support patching this.

Therefore, with Clang we generate .refptr stubs on all architectures. However it would be good to be able to opt out from them. When the variables actually end up autoimported, LLD has got a couple neat tricks that makes the actual pseudo relocations go away in most cases (when it can alias the .refptr.variable stub with the __imp_variable IAT entry). But for the cases when the variable isn't autoimported, the .refptr stub has to be kept, and it produces larger/slower code and more data than necessary. And for low level projects like Wine, it might be desireable to be able to tune exactly what is done.

So within the Clang context, it is not entirely about range (where the code model might be a reasonable fit), but about whether to be prepared for autoimports or not.

Within Clang, it is handled by marking variables we know are in the same DLL as dso_local, while variables that might be autoimported don't get that flag. Within LLVM, references to variables that aren't marked dso_local get indirection via a .refptr stub.

Possible ways of handling it would be to invent a new flag for this purpose; e.g. -fno-autoimport (with the corresponding -fautoimport meaning the default mode). That makes the use fairly clear, but its role is also a bit unclear; there are linker flags --disable-auto-import and --disable-runtime-pseudo-reloc which disable either autoimports of all sorts, or only autoimports that end up with an actual pseudo reloc (allowing the zero-cost ones that are aliased to IAT entries).

If we make the flag only affect code generation, having it named -fno-autoimport when the linker still may do something different (ending up with a pseudo relocation in executable code, which possibly still works fine, just less elegant) is unclear. If we on the other hand make the same flag imply either of --disable-auto-import or --disable-runtime-pseudo-reloc, then that name is rather clear.

If we only make it affect code generation, something like -fdso-local or -fno-refptr might be more precise.

If we make the flag imply linker options, then it becomes much clearer to spot the error, if you enabled this but the code base still would need autoimports somewhere. (This has happened - see https://code.videolan.org/videolan/dav1d/-/merge_requests/1303#note_301859, https://code.videolan.org/videolan/dav1d/-/merge_requests/1349 and https://code.videolan.org/videolan/dav1d/-/merge_requests/1361.) If we make the flag only affect code generation, it becomes a more clear match for projects using -mcmodel=small with GCC today.

I'm open for opinions on how to name these options, @alvinhochun @mati865 @jeremyd2019 and @jacek. Also requesting early guidance from @aaron.ballman.

[mati865]

If we make the flag imply linker options, then it becomes much clearer to spot the error, if you enabled this but the code base still would need autoimports somewhere. (This has happened - see https://code.videolan.org/videolan/dav1d/-/merge_requests/1303#note_301859, https://code.videolan.org/videolan/dav1d/-/merge_requests/1349 and https://code.videolan.org/videolan/dav1d/-/merge_requests/1361.) If we make the flag only affect code generation, it becomes a more clear match for projects using -mcmodel=small with GCC today.

LLVM already differs quite a bit from GNU in more "visible" parts like TLS so I'm don't see compelling reason to degrade user's experience just to be more compatible.
-fno-autoimport sounds fine for me.

[jacek]

-fno-autoimport sounds good to me. For linker implications, using --disable-auto-import in this case would seem consistent to me.

[mstorsjo]

Updated as discussed, adding a new option -fno-autoimport (and the corresponding positive one, -fautoimport, which is the implicit default), which affects code generation and linking.

The existing linker option --disable-auto-import (which is passed if this new option is set), splits "auto import" into two words - should the new Clang option try to harmonize with this spelling, making it -fno-auto-import instead?

[mstorsjo]

clang/include/clang/Driver/Options.td

1480

I see that most similar BoolFOptions for features that are DefaultTrue only document the NegFlag, which makes only the negative flag show up in clang --help. This is probably what one most commonly wants - but I see that the option ends up undocumented in ClangCommandLineReference.rst unless it has documentation for the PosFlag. So therefore I wrote documentation for both options here, and in a form where the PosFlag docs mostly is intended for the generated reference docs.

[rnk]

lgtm

cc +@aeubanks @jyknight to consider using the code model for this purpose

[mstorsjo]

In D61670#4604145, @rnk wrote:

cc +@aeubanks @jyknight to consider using the code model for this purpose

Hmm, I don't quite understand this comment; do you suggest that we after all should use the code model for controlling the use of .refptr stubs too - didn't we conclude earlier that it isn't a great fit for that?

[rnk]

In D61670#4604486, @mstorsjo wrote:

In D61670#4604145, @rnk wrote:

cc +@aeubanks @jyknight to consider using the code model for this purpose

Hmm, I don't quite understand this comment; do you suggest that we after all should use the code model for controlling the use of .refptr stubs too - didn't we conclude earlier that it isn't a great fit for that?

Sorry, let me elaborate. Since the first round of review, Arthur and James have been looking at x86 code models, in particular the medium code model. I guess what I really want to ask is, Arthur and James, do you agree with our decision that the code model should not control the formation of these COFF refptr stubs?

I expected the answer would be "yes", so I said "lgtm" and then phrased my question very awkwardly.

[mstorsjo]

I expected the answer would be "yes", so I said "lgtm" and then phrased my question very awkwardly.

Ah, thanks for the clarification!

Any opinion on the name, -fno-autoimport vs -fno-auto-import, given the existing linker option --disable-auto-import?

[aeubanks]

In D61670#4607313, @mstorsjo wrote:

I expected the answer would be "yes", so I said "lgtm" and then phrased my question very awkwardly.

Ah, thanks for the clarification!

Any opinion on the name, -fno-autoimport vs -fno-auto-import, given the existing linker option --disable-auto-import?

Is there an official name, "auto-import"/"autoimport"/"auto import"? Since cc1 flags are changeable and this hasn't landed yet, I think it'd be nice to standardize before we commit on a stable name.
If there isn't already a name, I like the dash in "auto-import".

In D61670#4604554, @rnk wrote:

In D61670#4604486, @mstorsjo wrote:

In D61670#4604145, @rnk wrote:

cc +@aeubanks @jyknight to consider using the code model for this purpose

Hmm, I don't quite understand this comment; do you suggest that we after all should use the code model for controlling the use of .refptr stubs too - didn't we conclude earlier that it isn't a great fit for that?

Sorry, let me elaborate. Since the first round of review, Arthur and James have been looking at x86 code models, in particular the medium code model. I guess what I really want to ask is, Arthur and James, do you agree with our decision that the code model should not control the formation of these COFF refptr stubs?

I expected the answer would be "yes", so I said "lgtm" and then phrased my question very awkwardly.

Yeah, at least with my understanding code models shouldn't change whether or not things are dso_local or not. They should only affect the instruction sequence we use to access globals/functions.

[mstorsjo]

In D61670#4611790, @aeubanks wrote:

In D61670#4607313, @mstorsjo wrote:

I expected the answer would be "yes", so I said "lgtm" and then phrased my question very awkwardly.

Ah, thanks for the clarification!

Any opinion on the name, -fno-autoimport vs -fno-auto-import, given the existing linker option --disable-auto-import?

Is there an official name, "auto-import"/"autoimport"/"auto import"?

Not really, no - it's all very much ad-hoc.

Since cc1 flags are changeable and this hasn't landed yet, I think it'd be nice to standardize before we commit on a stable name.
If there isn't already a name, I like the dash in "auto-import".

Ok, sounds reasonable - I'll change it into that form then.

[mstorsjo]

Updated to use the form -fno-auto-import and similar split it into two separate words everywhere.

[aeubanks]

I don't have all the context here, but seems fine once the commit description is updated with the new spelling

[mstorsjo]

In D61670#4621724, @aeubanks wrote:

I don't have all the context here, but seems fine once the commit description is updated with the new spelling

Thanks. Yeah I've updated the commit message locally (I wonder if the arc tool can resync the patch description? Although that's becoming irrelevant real soon now anyway.) I'll update the description here anyway, and I'll probably go ahead and push it in a few days if nobody else wants to comment on it.

clang/docs/ReleaseNotes.rst

 ^^^^^^^^^^^^^^^^^^^^^^^
 
 Windows Support
 ^^^^^^^^^^^^^^^
 - Fixed an assertion failure that occurred due to a failure to propagate
   ``MSInheritanceAttr`` attributes to class template instantiations created
   for explicit template instantiation declarations.
 
+- The ``-fno-auto-import`` option was added for MinGW targets. The option both
+  affects code generation (inhibiting generating indirection via ``.refptr``
+  stubs for potentially auto imported symbols, generating smaller and more
+  efficient code) and linking (making the linker error out on such cases).
+  If the option only is used during code generation but not when linking,
+  linking may succeed but the resulting executables may expose issues at
+  runtime.
+
 LoongArch Support
 ^^^^^^^^^^^^^^^^^
 
 RISC-V Support
 ^^^^^^^^^^^^^^
 - Unaligned memory accesses can be toggled by ``-m[no-]unaligned-access`` or the
   aliases ``-m[no-]strict-align``.
 

clang/include/clang/Basic/CodeGenOptions.def

 CODEGENOPT(RelaxELFRelocations, 1, 1) ///< -Wa,-mrelax-relocations={yes,no}
 CODEGENOPT(AsmVerbose        , 1, 0) ///< -dA, -fverbose-asm.
 CODEGENOPT(Dwarf64           , 1, 0) ///< -gdwarf64.
 CODEGENOPT(Dwarf32           , 1, 1) ///< -gdwarf32.
 CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.
 CODEGENOPT(AssumeSaneOperatorNew , 1, 1) ///< implicit __attribute__((malloc)) operator new
 CODEGENOPT(AssumeUniqueVTables , 1, 1) ///< Assume a class has only one vtable.
 CODEGENOPT(Autolink          , 1, 1) ///< -fno-autolink
+CODEGENOPT(AutoImport        , 1, 1) ///< -fno-auto-import
 CODEGENOPT(ObjCAutoRefCountExceptions , 1, 0) ///< Whether ARC should be EH-safe.
 CODEGENOPT(Backchain         , 1, 0) ///< -mbackchain
 CODEGENOPT(ControlFlowGuardNoChecks  , 1, 0) ///< -cfguard-no-checks
 CODEGENOPT(ControlFlowGuard  , 1, 0) ///< -cfguard
 CODEGENOPT(EHContGuard       , 1, 0) ///< -ehcontguard
 CODEGENOPT(CXAAtExit         , 1, 1) ///< Use __cxa_atexit for calling destructors.
 CODEGENOPT(RegisterGlobalDtorsWithAtExit, 1, 1) ///< Use atexit or __cxa_atexit to register global destructors.
 CODEGENOPT(CXXCtorDtorAliases, 1, 0) ///< Emit complete ctors/dtors as linker

clang/include/clang/Driver/Options.td

  NegFlag<SetFalse>>;
 
 defm autolink : BoolFOption<"autolink",
   CodeGenOpts<"Autolink">, DefaultTrue,
   NegFlag<SetFalse, [], [ClangOption, CC1Option],
           "Disable generation of linker directives for automatic library linking">,
   PosFlag<SetTrue>>;
 
+let Flags = [TargetSpecific] in {
+defm auto_import : BoolFOption<"auto-import",
+  CodeGenOpts<"AutoImport">, DefaultTrue,
+  NegFlag<SetFalse, [], [ClangOption, CC1Option],
+          "MinGW specific. Disable support for automatic dllimport in code generation "
+          "and linking">,
+  PosFlag<SetTrue, [], [], "MinGW specific. Enable code generation support for "
+          "automatic dllimport, and enable support for it in the linker. "
+          "Enabled by default.">>;
+} // let Flags = [TargetSpecific]
+
 // In the future this option will be supported by other offloading
 // languages and accept other values such as CPU/GPU architectures,
 // offload kinds and target aliases.
 def offload_EQ : CommaJoined<["--"], "offload=">, Flags<[NoXarchOption]>,
   HelpText<"Specify comma-separated list of offloading target triples (CUDA and HIP only)">;
 
 // C++ Coroutines
 defm coroutines : BoolFOption<"coroutines",

clang/lib/CodeGen/CodeGenModule.cpp

static bool shouldAssumeDSOLocal(const CodeGenModule &CGM,
   if (!GV->hasDefaultVisibility() && !GV->hasExternalWeakLinkage())
     return true;
 
   // DLLImport explicitly marks the GV as external.
   if (GV->hasDLLImportStorageClass())
     return false;
 
   const llvm::Triple &TT = CGM.getTriple();
+  const auto &CGOpts = CGM.getCodeGenOpts();
   if (TT.isWindowsGNUEnvironment()) {
     // In MinGW, variables without DLLImport can still be automatically
     // imported from a DLL by the linker; don't mark variables that
     // potentially could come from another DLL as DSO local.
 
     // With EmulatedTLS, TLS variables can be autoimported from other DLLs
     // (and this actually happens in the public interface of libstdc++), so
     // such variables can't be marked as DSO local. (Native TLS variables
     // can't be dllimported at all, though.)
     if (GV->isDeclarationForLinker() && isa<llvm::GlobalVariable>(GV) &&
-        (!GV->isThreadLocal() || CGM.getCodeGenOpts().EmulatedTLS))
+        (!GV->isThreadLocal() || CGM.getCodeGenOpts().EmulatedTLS) &&
+        CGOpts.AutoImport)
       return false;
   }
 
   // On COFF, don't mark 'extern_weak' symbols as DSO local. If these symbols
   // remain unresolved in the link, they can be resolved to zero, which is
   // outside the current DSO.
   if (TT.isOSBinFormatCOFF() && GV->hasExternalWeakLinkage())
     return false;
 
   // Every other GV is local on COFF.
   // Make an exception for windows OS in the triple: Some firmware builds use
   // *-win32-macho triples. This (accidentally?) produced windows relocations
   // without GOT tables in older clang versions; Keep this behaviour.
   // FIXME: even thread local variables?
   if (TT.isOSBinFormatCOFF() || (TT.isOSWindows() && TT.isOSBinFormatMachO()))
     return true;
 
   // Only handle COFF and ELF for now.
   if (!TT.isOSBinFormatELF())
     return false;
 
   // If this is not an executable, don't assume anything is local.
-  const auto &CGOpts = CGM.getCodeGenOpts();
   llvm::Reloc::Model RM = CGOpts.RelocationModel;
   const auto &LOpts = CGM.getLangOpts();
   if (RM != llvm::Reloc::Static && !LOpts.PIE) {
     // On ELF, if -fno-semantic-interposition is specified and the target
     // supports local aliases, there will be neither CC1
     // -fsemantic-interposition nor -fhalf-no-semantic-interposition. Set
     // dso_local on the function if using a local alias is preferable (can avoid
     // PLT indirection).

clang/lib/Driver/ToolChains/Clang.cpp

#endif
   if (KernelOrKext && RawTriple.isOSDarwin())
     CmdArgs.push_back("-fforbid-guard-variables");
 
   if (Args.hasFlag(options::OPT_mms_bitfields, options::OPT_mno_ms_bitfields,
                    Triple.isWindowsGNUEnvironment())) {
     CmdArgs.push_back("-mms-bitfields");
   }
 
+  if (Triple.isWindowsGNUEnvironment()) {
+    Args.addOptOutFlag(CmdArgs, options::OPT_fauto_import,
+                       options::OPT_fno_auto_import);
+  }
+
   // Non-PIC code defaults to -fdirect-access-external-data while PIC code
   // defaults to -fno-direct-access-external-data. Pass the option if different
   // from the default.
   if (Arg *A = Args.getLastArg(options::OPT_fdirect_access_external_data,
                                options::OPT_fno_direct_access_external_data))
     if (A->getOption().matches(options::OPT_fdirect_access_external_data) !=
         (PICLevel == 0))
       A->render(Args, CmdArgs);

clang/lib/Driver/ToolChains/MinGW.cpp

if (Args.hasArg(options::OPT_mdll) || Args.hasArg(options::OPT_shared)) {
     else
       CmdArgs.push_back("DllMainCRTStartup");
     CmdArgs.push_back("--enable-auto-image-base");
   }
 
   if (Args.hasArg(options::OPT_Z_Xlinker__no_demangle))
     CmdArgs.push_back("--no-demangle");
 
+  if (!Args.hasFlag(options::OPT_fauto_import, options::OPT_fno_auto_import,
+                    true))
+    CmdArgs.push_back("--disable-auto-import");
+
   if (Arg *A = Args.getLastArg(options::OPT_mguard_EQ)) {
     StringRef GuardArgs = A->getValue();
     if (GuardArgs == "none")
       CmdArgs.push_back("--no-guard-cf");
     else if (GuardArgs == "cf" || GuardArgs == "cf-nochecks")
       CmdArgs.push_back("--guard-cf");
     else
       D.Diag(diag::err_drv_unsupported_option_argument)

clang/test/CodeGen/dso-local-executable.c

 // RUN: %clang_cc1 -triple x86_64-pc-win32 -emit-llvm %s -o - | FileCheck --check-prefix=COFF %s
 // COFF:      @baz = dso_local global i32 42
 // COFF-NEXT: @import_var = external dllimport global i32
 // COFF-NEXT: @weak_bar = extern_weak global i32
 // COFF-NEXT: @bar = external dso_local global i32
 // COFF-NEXT: @local_thread_var = dso_local thread_local global i32 42
 // COFF-NEXT: @thread_var = external dso_local thread_local global i32
 // COFF-DAG: declare dso_local void @foo()
 // COFF-DAG: define dso_local ptr @zed()
 // COFF-DAG: declare dllimport void @import_func()
 
-// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - | FileCheck --check-prefixes=MINGW,MINGW-NATIVE_TLS %s
-// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - -femulated-tls | FileCheck --check-prefixes=MINGW,MINGW-EMUTLS %s
+// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - | FileCheck --check-prefixes=MINGW,MINGW-NATIVE_TLS,MINGW-AUTO-IMPORT %s
+// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - -fno-auto-import | FileCheck --check-prefixes=MINGW,MINGW-NATIVE_TLS,MINGW-NO-AUTO-IMPORT %s
+// RUN: %clang_cc1 -triple x86_64-w64-mingw32 -emit-llvm %s -o - -femulated-tls | FileCheck --check-prefixes=MINGW,MINGW-EMUTLS,MINGW-AUTO-IMPORT %s
 // MINGW:      @baz = dso_local global i32 42
 // MINGW-NEXT: @import_var = external dllimport global i32
 // MINGW-NEXT: @weak_bar = extern_weak global i32
-// MINGW-NEXT: @bar = external global i32
+// MINGW-AUTO-IMPORT-NEXT: @bar = external global i32
+// MINGW-NO-AUTO-IMPORT-NEXT: @bar = external dso_local global i32
 // MINGW-NEXT: @local_thread_var = dso_local thread_local global i32 42
 // MINGW-NATIVE_TLS-NEXT: @thread_var = external dso_local thread_local global i32
 // MINGW-EMUTLS-NEXT: @thread_var = external thread_local global i32
 // MINGW-DAG: declare dso_local void @foo()
 // MINGW-DAG: define dso_local ptr @zed()
 // MINGW-DAG: declare dllimport void @import_func()
 
 /// Static relocation model defaults to -fdirect-access-external-data and sets

clang/test/Driver/mingw-auto-import.c

+// By default, we don't pass any -fauto-import to -cc1, as that's the default.
+//
+// RUN: %clang --target=x86_64-w64-windows-gnu -### %s 2>&1 | FileCheck --check-prefixes=DEFAULT %s
+// RUN: %clang --target=x86_64-w64-windows-gnu -fno-auto-import -fauto-import -### %s 2>&1 | FileCheck --check-prefixes=DEFAULT %s
+// DEFAULT: "-cc1"
+// DEFAULT-NOT: no-auto-import
+// DEFAULT-NOT: --disable-auto-import
+
+// When compiling with -fno-auto-import, we pass -fno-auto-import to -cc1
+// and --disable-auto-import to the linker.
+//
+// RUN: %clang --target=x86_64-w64-windows-gnu -fauto-import -fno-auto-import -### %s 2>&1 | FileCheck --check-prefixes=NO_AUTOIMPORT %s
+// NO_AUTOIMPORT: "-cc1"
+// NO_AUTOIMPORT: "-fno-auto-import"
+// NO_AUTOIMPORT: "--disable-auto-import"