clang-cl: Add "/clang:" pass-through arg support.

[neerajksingh]

Summary

The clang-cl driver disables access to command line options outside of the
"Core" and "CLOption" sets of command line arguments. This filtering makes it
impossible to pass arguments that are interpreted by the clang driver and not
by either 'cc1' (the frontend) or one of the other tools invoked by the driver.

An example driver-level flag is the '-fno-slp-vectorize' flag, which is
processed by the driver in Clang::ConstructJob and used to set the cc1 flag
"-vectorize-slp". There is no negative cc1 flag or -mllvm flag, so it is not
currently possible to disable the SLP vectorizer from the clang-cl driver.

This change introduces the "/clang:" argument that is available when the
driver mode is set to CL compatibility. This option works similarly to the
"-Xclang" option, except that the option values are processed by the clang
driver rather than by 'cc1'. An example usage is:

clang-cl /clang:-fno-slp-vectorize /O2 test.c

Another example shows how "/clang:" can be used to pass a flag where there is
a conflict between a clang-cl compat option and an overlapping clang driver
option:

clang-cl /MD /clang:-MD /clang:-MF /clang:test_dep_file.dep test.c

In the previous example, the unprefixed /MD selects the DLL version of the msvc
CRT, while the prefixed -MD flag and the -MF flags are used to create a make
dependency file for included headers.

One note about flag ordering: the /clang: flags are concatenated to the end of
the argument list, so in cases where the last flag wins, the /clang: flags
will be chosen regardless of their order relative to other flags on the driver
command line.

[hans]

I haven't started looking at the code yet.

I'm not completely convinced that we want this. So far we've used the strategy of promoting clang options that are also useful in clang-cl to core options, and if someone wants to use more clang than that, maybe clang-cl isn't the right driver for that use-case.

But I suppose an argument could be made for having an escape hatch from clang-cl if it doesn't add too much complexity to the code.

I'm not sure I'm a fan of calling it /Xdriver: though, because what does it mean - clang-cl is the driver, but the option refers to the clang driver. The natural name would of course be -Xclang but that already means something else. Maybe we could just call it /clang:

[rnk]

In D53457#1269769, @hans wrote:

I haven't started looking at the code yet.

I'm not completely convinced that we want this. So far we've used the strategy of promoting clang options that are also useful in clang-cl to core options, and if someone wants to use more clang than that, maybe clang-cl isn't the right driver for that use-case.

But I suppose an argument could be made for having an escape hatch from clang-cl if it doesn't add too much complexity to the code.

Personally, I really want to get out of the role of being a gatekeeper for GCC-style driver flags. I want users to be able to solve their own problems without building clang-cl from scratch or waiting for the next 6 month release.

I'm personally in favor of moving clang-cl to a blacklist model instead of a whitelist model so that we go even further in this direction, but it doesn't address what to do about conflicting or ambiguous options like -MD. An escape hatch like [-/]Xdriver: seems like a useful thing to have when that arises.

I'm not sure I'm a fan of calling it /Xdriver: though, because what does it mean - clang-cl is the driver, but the option refers to the clang driver. The natural name would of course be -Xclang but that already means something else. Maybe we could just call it /clang:

Huh, I like that. You'd also be able to spell it -clang:, so the leading / is less of a disambiguator, but the colon is clearly a sign that this is a CL-style option.

[neerajksingh]

In D53457#1269769, @hans wrote:

I'm not completely convinced that we want this. So far we've used the strategy of promoting clang options that are also useful in clang-cl to core options, and if someone wants to use more clang than that, maybe clang-cl isn't the right driver for that use-case.

But I suppose an argument could be made for having an escape hatch from clang-cl if it doesn't add too much complexity to the code.

This is a good point. However, having this escape hatch gets you and Reid and others out of the business of having to promote options. Also, as new flags are added to the compiler people might need one revision of the official builds to realize they need a flag and one revision to get the flag added to the binary release. This obviously isn't a problem for people building Clang from source, but it does add unnecessary friction as I found myself.

I'm not sure I'm a fan of calling it /Xdriver: though, because what does it mean - clang-cl is the driver, but the option refers to the clang driver. The natural name would of course be -Xclang but that already means something else. Maybe we could just call it /clang:

At the conference last week I discussed this with Reid Kleckner. One of the options we discussed was trying to make things work such that -Xclang serves both purposes. We quickly decided that this wouldn't work. /clang: would be fine, but it might be more confusing since people will wonder what's the difference between /Xclang and /clang:. We could use something more verbose like /Xclang-driver:. I'd be happy to change the flag to whatever spelling will build consensus.

[hans]

In D53457#1271046, @neerajksingh wrote:

In D53457#1269769, @hans wrote:

I'm not completely convinced that we want this. So far we've used the strategy of promoting clang options that are also useful in clang-cl to core options, and if someone wants to use more clang than that, maybe clang-cl isn't the right driver for that use-case.

But I suppose an argument could be made for having an escape hatch from clang-cl if it doesn't add too much complexity to the code.

This is a good point. However, having this escape hatch gets you and Reid and others out of the business of having to promote options. Also, as new flags are added to the compiler people might need one revision of the official builds to realize they need a flag and one revision to get the flag added to the binary release. This obviously isn't a problem for people building Clang from source, but it does add unnecessary friction as I found myself.

Yeah, let's add the escape hatch.

I'm not sure I'm a fan of calling it /Xdriver: though, because what does it mean - clang-cl is the driver, but the option refers to the clang driver. The natural name would of course be -Xclang but that already means something else. Maybe we could just call it /clang:

At the conference last week I discussed this with Reid Kleckner. One of the options we discussed was trying to make things work such that -Xclang serves both purposes. We quickly decided that this wouldn't work. /clang: would be fine, but it might be more confusing since people will wonder what's the difference between /Xclang and /clang:. We could use something more verbose like /Xclang-driver:. I'd be happy to change the flag to whatever spelling will build consensus.

Let's go with "/clang:" for the flag.

I don't think having both that and -Xclang would be too confusing. I think -Xclang is undocumented anyway and really something that should just be used by experts. We should add /clang: to the documentation and I think it will be straight-forward to understand.

[thakis]

Comment from the peanut gallery:

• I like the whitelist model for gcc-style flags. It allows us to curate them (and /? output) since many don't make much sense in the cl world.
• I like the idea behind this patch (and /clang: seems like a good spelling)

[neerajksingh]

Change the spelling of from "/Xdriver:" to "/clang:".

Refactor getIncludeExcludeOptionFlagMasks to take whether we're in CL mode as an argument, making the function pure.

[hans]

One note about flag ordering: the /clang: flags are concatenated to the end of
the argument list, so in cases where the last flag wins, the /clang: flags
will be chosen regardless of their order relative to other flags on the driver
command line.

This seems a little unfortunate. I wonder if it would be possible to not have this restriction, i.e. to process these in-line with the rest of the flags?

One way to achieve this would be to change Driver::ParseArgStrings() to handle the "/clang:" arguments. After doing the regular option parsing, it would look for "/clang:" options and substitute them for the underlying option. This has the downside of adding some option-specific logic to ParseArgStrings, but on the other hand it's less intrusive than passing around the IsCLMode bool. Do you think something like this could work?

docs/UsersManual.rst

3100

Thanks for thinking about the docs!

I think we should put this above the /fallback section, since this new flag is more important and /fallback shouldn't be used much these days.

include/clang/Driver/CLCompatOptions.td

324

Do we really want the "OrSeparate" part of this? Is there any downside of limiting it to "/clang:-foo" rather than also allowing "/clang: -foo"?

[neerajksingh]

In D53457#1277315, @hans wrote:

One note about flag ordering: the /clang: flags are concatenated to the end of
the argument list, so in cases where the last flag wins, the /clang: flags
will be chosen regardless of their order relative to other flags on the driver
command line.

This seems a little unfortunate. I wonder if it would be possible to not have this restriction, i.e. to process these in-line with the rest of the flags?

One way to achieve this would be to change Driver::ParseArgStrings() to handle the "/clang:" arguments. After doing the regular option parsing, it would look for "/clang:" options and substitute them for the underlying option. This has the downside of adding some option-specific logic to ParseArgStrings, but on the other hand it's less intrusive than passing around the IsCLMode bool. Do you think something like this could work?

One difficulty occurs with options that have separated values, like the /clang:-MF /clang:<filename> case. In this case, we need to take two /clang: arguments and process them next to each other in order to form a single coherent argument/value pair. Another option is to allow the user to specify the option like /clang:"-MF <filename>" and then require that the user specify any flags that need a value in a single /clang: argument. This would require some code to split the value string on spaces before passing it on to clang argument parsing.

Do you have any preference or better suggestion for the option-with-value case?

[neerajksingh]

Fix hans' comments.

[hans]

In D53457#1277950, @neerajksingh wrote:

In D53457#1277315, @hans wrote:

One note about flag ordering: the /clang: flags are concatenated to the end of
the argument list, so in cases where the last flag wins, the /clang: flags
will be chosen regardless of their order relative to other flags on the driver
command line.

This seems a little unfortunate. I wonder if it would be possible to not have this restriction, i.e. to process these in-line with the rest of the flags?

One way to achieve this would be to change Driver::ParseArgStrings() to handle the "/clang:" arguments. After doing the regular option parsing, it would look for "/clang:" options and substitute them for the underlying option. This has the downside of adding some option-specific logic to ParseArgStrings, but on the other hand it's less intrusive than passing around the IsCLMode bool. Do you think something like this could work?

One difficulty occurs with options that have separated values, like the /clang:-MF /clang:<filename> case. In this case, we need to take two /clang: arguments and process them next to each other in order to form a single coherent argument/value pair. Another option is to allow the user to specify the option like /clang:"-MF <filename>" and then require that the user specify any flags that need a value in a single /clang: argument. This would require some code to split the value string on spaces before passing it on to clang argument parsing.

Do you have any preference or better suggestion for the option-with-value case?

The -Xclang option has the same issue, and I think /clang: should work similarly, i.e. /clang:-MF /clang:<filename>. It's not pretty, but at least it's consistent. Yes, that means processing consecutive /Xclang: options together, but hopefully that's doable.

[neerajksingh]

In D53457#1278579, @hans wrote:

The -Xclang option has the same issue, and I think /clang: should work similarly, i.e. /clang:-MF /clang:<filename>. It's not pretty, but at least it's consistent. Yes, that means processing consecutive /Xclang: options together, but hopefully that's doable.

It looks like the handling for -Xclang is a lot simpler (in Clang::ConstructJob). There the Xclang options are all gathered and forwarded at a particular spot in the command line for cc1. They aren't interleaved with other options, and it wouldn't really make sense to do so anyway since it doesn't really look like cc1 arguments are constructed from driver arguments in any particular order.

The llvm/lib/Option/OptTable.cpp code is not really setup to easily interleave arguments like would be required for your request. Can you see a way to accomplish what you want without a deep refactoring of OptTable::ParseArgs and the InputArgList class?

[hans]

In D53457#1279191, @neerajksingh wrote:

In D53457#1278579, @hans wrote:

The -Xclang option has the same issue, and I think /clang: should work similarly, i.e. /clang:-MF /clang:<filename>. It's not pretty, but at least it's consistent. Yes, that means processing consecutive /Xclang: options together, but hopefully that's doable.

It looks like the handling for -Xclang is a lot simpler (in Clang::ConstructJob). There the Xclang options are all gathered and forwarded at a particular spot in the command line for cc1. They aren't interleaved with other options, and it wouldn't really make sense to do so anyway since it doesn't really look like cc1 arguments are constructed from driver arguments in any particular order.

The llvm/lib/Option/OptTable.cpp code is not really setup to easily interleave arguments like would be required for your request. Can you see a way to accomplish what you want without a deep refactoring of OptTable::ParseArgs and the InputArgList class?

Okay, if it's hard to do, I suppose collecting the /clang: options and processing them separately after the others is the second-best option. We'll need to make sure the behaviour is well-documented.

[neerajksingh]

Make it clear in the documentation that the /clang flags are added to the end.

[hans]

Okay, looks good to me (with a small nit).

docs/UsersManual.rst

2852

ultra nit: no space between the colon and <arg>

test/Driver/cl-options.c

619

I'm not sure this test adds much value..

[neerajksingh]

Will update revision...

test/Driver/cl-options.c

619

This test ensures that the next test is actually testing something (i.e. that the settings change between the two runs).

[neerajksingh]

Reid, Hans, or someone else with commit access. If the revision looks good, could you please submit to SVN?

Any particular testing I should run beforehand? I ran the clang tests locally on Windows.

[hans]

In D53457#1291020, @neerajksingh wrote:

Reid, Hans, or someone else with commit access. If the revision looks good, could you please submit to SVN?

Any particular testing I should run beforehand? I ran the clang tests locally on Windows.

I'll run the tests on Linux and commit.

[thakis]

I noticed that this causes memory errors in certain situations. https://bugs.llvm.org/show_bug.cgi?id=42501 has details. Can you take a look?

docs/UsersManual.rst

Execute ``clang-cl /?`` to see a list of supported options:
 
   ::
 
     CL.EXE COMPATIBILITY OPTIONS:
       /?                      Display available options
       /arch:<value>           Set architecture for code generation
       /Brepro-                Emit an object file which cannot be reproduced over time
       /Brepro                 Emit an object file which can be reproduced over time
+      /clang: <arg>           Pass <arg> to the clang driver
       /C                      Don't discard comments when preprocessing
       /c                      Compile only
       /d1PP                   Retain macro definitions in /E mode
       /d1reportAllClassLayout Dump record layout information
       /diagnostics:caret      Enable caret and column diagnostics (on by default)
       /diagnostics:classic    Disable column and caret diagnostics
       /diagnostics:column     Disable caret diagnostics but keep column info
       /D <macro[=value]>      Define macro

 When clang-cl is run with the ``/fallback`` option, it will first try to
 compile files itself. For any file that it fails to compile, it will fall back
 and try to compile the file by invoking cl.exe.
 
 This option is intended to be used as a temporary means to build projects where
 clang-cl cannot successfully compile all the files. clang-cl may fail to compile
 a file either because it cannot generate code for some C++ feature, or because
 it cannot parse some Microsoft language extension.
+
+The /clang: Option
+^^^^^^^^^^^^^^^^^^^^
+
+When clang-cl is run with a set of ``/clang:<arg>`` options, it will gather all
+of the ``<arg>`` arguments and process them as if they were passed to the clang
+driver. This mechanism allows you to pass flags that are not exposed in the
+clang-cl options or flags that have a different meaning when passed to the clang
+driver.

include/clang/Driver/CLCompatOptions.td

def _SLASH_vmm : CLFlag<"vmm">,
   HelpText<"Set the default most-general representation to "
            "multiple inheritance">;
 def _SLASH_vmv : CLFlag<"vmv">,
   HelpText<"Set the default most-general representation to "
            "virtual inheritance">;
 def _SLASH_volatile_ms  : Option<["/", "-"], "volatile:ms", KIND_FLAG>,
   Group<_SLASH_volatile_Group>, Flags<[CLOption, DriverOption]>,
   HelpText<"Volatile loads and stores have acquire and release semantics">;
+def _SLASH_clang : CLJoinedOrSeparate<"clang:">,
+  HelpText<"Pass <arg> to the clang driver">, MetaVarName<"<arg>">;
 def _SLASH_Zl : CLFlag<"Zl">,
   HelpText<"Don't mention any default libraries in the object file">;
 
 def _SLASH_Yc : CLJoined<"Yc">,
   HelpText<"Generate a pch file for all code up to and including <filename>">,
   MetaVarName<"<filename>">;
 def _SLASH_Yu : CLJoined<"Yu">,
   HelpText<"Load a pch file and use it instead of all code up to "

include/clang/Driver/Driver.h

public:
   /// @{
 
   /// ParseDriverMode - Look for and handle the driver mode option in Args.
   void ParseDriverMode(StringRef ProgramName, ArrayRef<const char *> Args);
 
   /// ParseArgStrings - Parse the given list of strings into an
   /// ArgList.
   llvm::opt::InputArgList ParseArgStrings(ArrayRef<const char *> Args,
+                                          bool IsClCompatMode,
                                           bool &ContainsError);
 
   /// BuildInputs - Construct the list of inputs and their types from
   /// the given arguments.
   ///
   /// \param TC - The default host tool chain.
   /// \param Args - The input arguments.
   /// \param Inputs - The list to store the resulting compilation
private:
   /// on-demand.
   const ToolChain &getToolChain(const llvm::opt::ArgList &Args,
                                 const llvm::Triple &Target) const;
 
   /// @}
 
   /// Get bitmasks for which option flags to include and exclude based on
   /// the driver mode.
-  std::pair<unsigned, unsigned> getIncludeExcludeOptionFlagMasks() const;
+  std::pair<unsigned, unsigned> getIncludeExcludeOptionFlagMasks(bool IsClCompatMode) const;
 
   /// Helper used in BuildJobsForAction.  Doesn't use the cache when building
   /// jobs specifically for the given action, but will use the cache when
   /// building jobs for the Action's inputs.
   InputInfo BuildJobsForActionNoCache(
       Compilation &C, const Action *A, const ToolChain *TC, StringRef BoundArch,
       bool AtTopLevel, bool MultipleArchs, const char *LinkingOutput,
       std::map<std::pair<const Action *, std::string>, InputInfo>

lib/Driver/Driver.cpp

if (auto M = llvm::StringSwitch<llvm::Optional<DriverMode>>(Value)
                    .Case("cl", CLMode)
                    .Default(None))
     Mode = *M;
   else
     Diag(diag::err_drv_unsupported_option_argument) << OptName << Value;
 }
 
 InputArgList Driver::ParseArgStrings(ArrayRef<const char *> ArgStrings,
+                                     bool IsClCompatMode,
                                      bool &ContainsError) {
   llvm::PrettyStackTraceString CrashInfo("Command line argument parsing");
   ContainsError = false;
 
   unsigned IncludedFlagsBitmask;
   unsigned ExcludedFlagsBitmask;
   std::tie(IncludedFlagsBitmask, ExcludedFlagsBitmask) =
-      getIncludeExcludeOptionFlagMasks();
+      getIncludeExcludeOptionFlagMasks(IsClCompatMode);
 
   unsigned MissingArgIndex, MissingArgCount;
   InputArgList Args =
       getOpts().ParseArgs(ArgStrings, MissingArgIndex, MissingArgCount,
                           IncludedFlagsBitmask, ExcludedFlagsBitmask);
 
   // Check for missing argument error.
   if (MissingArgCount) {
bool Driver::readConfigFile(StringRef FileName) {
   }
 
   // Read options from config file.
   llvm::SmallString<128> CfgFileName(FileName);
   llvm::sys::path::native(CfgFileName);
   ConfigFile = CfgFileName.str();
   bool ContainErrors;
   CfgOptions = llvm::make_unique<InputArgList>(
-      ParseArgStrings(NewCfgArgs, ContainErrors));
+      ParseArgStrings(NewCfgArgs, IsCLMode(), ContainErrors));
   if (ContainErrors) {
     CfgOptions.reset();
     return true;
   }
 
   if (CfgOptions->hasArg(options::OPT_config)) {
     CfgOptions.reset();
     Diag(diag::err_drv_nested_config_file);
Compilation *Driver::BuildCompilation(ArrayRef<const char *> ArgList) {
   // how other options are parsed.
   ParseDriverMode(ClangExecutable, ArgList.slice(1));
 
   // FIXME: What are we going to do with -V and -b?
 
   // Arguments specified in command line.
   bool ContainsError;
   CLOptions = llvm::make_unique<InputArgList>(
-      ParseArgStrings(ArgList.slice(1), ContainsError));
+      ParseArgStrings(ArgList.slice(1), IsCLMode(), ContainsError));
 
   // Try parsing configuration file.
   if (!ContainsError)
     ContainsError = loadConfigFile();
   bool HasConfigFile = !ContainsError && (CfgOptions.get() != nullptr);
 
   // All arguments, from both config file and command line.
   InputArgList Args = std::move(HasConfigFile ? std::move(*CfgOptions)
                                               : std::move(*CLOptions));
-  if (HasConfigFile)
-    for (auto *Opt : *CLOptions) {
-      if (Opt->getOption().matches(options::OPT_config))
-        continue;
+
+  auto appendOneArg = [&Args](const Arg *Opt, const Arg *BaseArg) {
       unsigned Index = Args.MakeIndex(Opt->getSpelling());
-      const Arg *BaseArg = &Opt->getBaseArg();
-      if (BaseArg == Opt)
-        BaseArg = nullptr;
       Arg *Copy = new llvm::opt::Arg(Opt->getOption(), Opt->getSpelling(),
                                      Index, BaseArg);
       Copy->getValues() = Opt->getValues();
       if (Opt->isClaimed())
         Copy->claim();
       Args.append(Copy);
-    }
+  };
+
+  if (HasConfigFile)
+    for (auto *Opt : *CLOptions) {
+      if (Opt->getOption().matches(options::OPT_config))
+        continue;
+      const Arg *BaseArg = &Opt->getBaseArg();
+      if (BaseArg == Opt)
+        BaseArg = nullptr;
+      appendOneArg(Opt, BaseArg);
+    }
+
+  // In CL mode, look for any pass-through arguments
+  if (IsCLMode() && !ContainsError) {
+    SmallVector<const char *, 16> CLModePassThroughArgList;
+    for (const auto *A : Args.filtered(options::OPT__SLASH_clang)) {
+      A->claim();
+      CLModePassThroughArgList.push_back(A->getValue());
+    }
+
+    if (!CLModePassThroughArgList.empty()) {
+      // Parse any pass through args using default clang processing rather
+      // than clang-cl processing.
+      auto CLModePassThroughOptions = llvm::make_unique<InputArgList>(
+          ParseArgStrings(CLModePassThroughArgList, false, ContainsError));
+
+      if (!ContainsError)
+        for (auto *Opt : *CLModePassThroughOptions) {
+          appendOneArg(Opt, nullptr);
+        }
+    }
 
   // FIXME: This stuff needs to go into the Compilation, not the driver.
   bool CCCPrintPhases;
 
   // Silence driver warnings if requested
   Diags.setIgnoreAllWarnings(Args.hasArg(options::OPT_w));
 
   // -no-canonical-prefixes is used very early in main.
#endif
   }
   return Res;
 }
 
 void Driver::PrintHelp(bool ShowHidden) const {
   unsigned IncludedFlagsBitmask;
   unsigned ExcludedFlagsBitmask;
   std::tie(IncludedFlagsBitmask, ExcludedFlagsBitmask) =
-      getIncludeExcludeOptionFlagMasks();
+      getIncludeExcludeOptionFlagMasks(IsCLMode());
 
   ExcludedFlagsBitmask |= options::NoDriverOption;
   if (!ShowHidden)
     ExcludedFlagsBitmask |= HelpHidden;
 
   std::string Usage = llvm::formatv("{0} [options] file...", Name).str();
   getOpts().PrintHelp(llvm::outs(), Usage.c_str(), DriverTitle.c_str(),
                       IncludedFlagsBitmask, ExcludedFlagsBitmask,
while (CurDigit < Digits.size()) {
     Str = Str.drop_front(1);
     CurDigit++;
   }
 
   // More digits than requested, bail out...
   return false;
 }
 
-std::pair<unsigned, unsigned> Driver::getIncludeExcludeOptionFlagMasks() const {
+std::pair<unsigned, unsigned> Driver::getIncludeExcludeOptionFlagMasks(bool IsClCompatMode) const {
   unsigned IncludedFlagsBitmask = 0;
   unsigned ExcludedFlagsBitmask = options::NoDriverOption;
 
-  if (Mode == CLMode) {
+  if (IsClCompatMode) {
     // Include CL and Core options.
     IncludedFlagsBitmask |= options::CLOption;
     IncludedFlagsBitmask |= options::CoreOption;
   } else {
     ExcludedFlagsBitmask |= options::CLOption;
   }
 
   return std::make_pair(IncludedFlagsBitmask, ExcludedFlagsBitmask);
 }
 
 bool clang::driver::isOptimizationLevelFast(const ArgList &Args) {
   return Args.hasFlag(options::OPT_Ofast, options::OPT_O_Group, false);
 }

test/Driver/cl-options.c

 // RUN:     -flimit-debug-info \
 // RUN:     -flto \
 // RUN:     -fmerge-all-constants \
 // RUN:     -no-canonical-prefixes \
 // RUN:     -march=skylake \
 // RUN:     --version \
 // RUN:     -Werror /Zs -- %s 2>&1
 
+// Accept clang options under the /clang: flag.
+
+// RUN: %clang_cl -O2 -### -- %s 2>&1 | FileCheck -check-prefix=NOCLANG %s
+// NOCLANG: "--dependent-lib=libcmt"
+// NOCLANG-SAME: "-vectorize-slp"
+// NOCLANG-NOT: "--dependent-lib=msvcrt"
+
+// RUN: %clang_cl -O2 -MD /clang:-fno-slp-vectorize /clang:-MD /clang:-MF /clang:my_dependency_file.dep -### -- %s 2>&1 | FileCheck -check-prefix=CLANG %s
+// CLANG: "--dependent-lib=msvcrt"
+// CLANG-SAME: "-dependency-file" "my_dependency_file.dep"
+// CLANG-NOT: "--dependent-lib=libcmt"
+// CLANG-NOT: "-vectorize-slp"
 
 void f() { }