[clang] [Driver] More flexible rules for loading default configs

[mgorny]

Summary

Change the default config file loading logic to be more flexible
and more readable at the same time. The new algorithm focuses on four
locations, in order:

1. <triple>-<mode>.cfg using real driver mode
2. <triple>-<mode>.cfg using executable suffix
3. <triple>.cfg + <mode>.cfg using real driver mode
4. <triple>.cfg + <mode>.cfg using executable suffix

This is meant to preserve reasonable level of compatibility with
the existing use, while introducing more flexibility and making the code
simpler. Notably:

1. In this layout, the actual target triple is normally respected, and e.g. in -m32 build the x86_64-* configs will never be used.

2. Both real driver mode (preferable) and executable suffix are supported. This permits correctly handling calls with explicit --driver-mode= while at the same time preserving compatibility with the existing code.

3. The first two locations provide users with the ability to override configuration per specific target+mode combinaton, while the next two make it possible to independently specify per-target and per-mode configuration.

4. All config file locations are applicable independently of whether clang is started via a prefixed executable, or bare clang.

5. If the target is not explicitly specified and the executable prefix does not name a valid triple, it is used instead of the actual target triple for backwards compatibility.

This is particularly meant to address Gentoo's use case for
configuration files: to configure the default runtimes (i.e. -rtlib=,
-stdlib=) and --gcc-install-dir= for all the relevant drivers,
as well as to make it more convenient for users to override -W flags
to test compatibility with future versions of Clang easier.

[mgorny]

@sepavloff, I'd appreciate if you could take a look at the logic before I start updating tests.

[mgorny]

To explain this better, let's take the following example call:

x86_64-pc-linux-gnu-clang --driver-mode=g++ -target i386

This maps to:

• effective triple: i386 (from -target)
• effective mode: clang++ (from --driver-mode)
• name prefix: x86_64-pc-linux-gnu
• "fixed" name prefix: i386-pc-linux-gnu (with arch substituted based on effective triple)
• name suffix: clang

The algorithm will first try to use the first of the following configuration files:

1. i386-clang++.cfg (effective triple + effective mode)
2. i386-pc-linux-gnu-clang.cfg ("fixed" prefix + suffix)
3. x86_64-pc-linux-gnu-clang.cfg (orig. prefix + suffix)

If neither of these files are found, it will try to load one config file for the target and another for the driver.

For target, it will try:

1. i386.cfg (effective triple)
2. i386-pc-linux-gnu.cfg ("fixed" prefix)
3. x86_64-pc-linux-gnu.cfg (orig. prefix)

For driver, it will try:

1. clang++.cfg (effective mode)
2. clang.cfg (suffix)

This version doesn't include any further fallback, i.e. assumes we need to cover all triples and driver modes we care about. However, adding one should be trivial.

clang/lib/Driver/Driver.cpp

1074–1089

This part is mostly proof-of-concept, I need to look into how to do this properly.

[mgorny]

Simplify getting driver mode — it turns out it's set for us already!

[MaskRay]

clang/lib/Driver/Driver.cpp

6215

If the switch covers all enum members, we typically use llvm_unreachable to work around a GCC -Wswitch warning.
Clang correctly knows all branches are covered and do not need llvm_unreachable

[mgorny]

@sepavloff, gentle ping. I'm waiting for your ACK/NAK on the algo in https://reviews.llvm.org/D134337#3805368.

[sepavloff]

I would propose to slightly modify the config file search algorithm.

For the tool named as x86_64-pc-linux-gnu-clang, the existing algorithm would search for the files:

• i386-clang.cfg
• i386.cfg
• x86_64-clang.cfg
• x86_64.cfg

We could modify this algorithm to obtain more flexible one and still preserve backward compatibility as much as possible. Let's use the invocation x86_64-pc-linux-gnu-clang --driver-mode=g++ -target i386 as example and see what files the tool would search for in the modified algorithm.

First clang tries to find x86_64-pc-linux-gnu-clang.cfg. Just tool name with added suffix cfg. No target override, no attempt to split tool name into components. It provides possibility to have a separate configuration for any tool. The existing mechanism does not search for such file, so compatibility cannot be broken. This variant makes it possible to use configuration file even if tool name is arbitrary and does not follow usual pattern.

If x86_64-pc-linux-gnu-clang.cfg is found, it is loaded as configuration file and that's all. Otherwise the middle components are dropped and only target prefix and driver mode suffix are used for the search. It is similar to the search made by existing implementation, the following files that are looked for :

• i386-clang.cfg
• i386.cfg
• x86_64-clang.cfg
• x86_64.cfg

If the file found has form target.cfg or none of the files was found, clang tries to load driver-mode configuration file. The files are the same as in your algorithm:

• clang++.cfg
• clang.cfg

The driver-mode configuration is loaded prior to the target config, - as it may contain default settings that target config may override. In the current implementation such files are not, risk of breaking compatibility is minimal.

What do you think about this variant? Does it fit your use case?

[mgorny]

In D134337#3813779, @sepavloff wrote:

First clang tries to find x86_64-pc-linux-gnu-clang.cfg. Just tool name with added suffix cfg. No target override, no attempt to split tool name into components. It provides possibility to have a separate configuration for any tool. The existing mechanism does not search for such file, so compatibility cannot be broken. This variant makes it possible to use configuration file even if tool name is arbitrary and does not follow usual pattern.

That's incorrect. The existing algorithm uses precisely this file if that's how clang is named:

$ ./bin/x86_64-pc-linux-gnu-clang --version
clang version 16.0.0 ([e-mail]:llvm/llvm-project.git 17779984ca4441657071ea5abe6ef2bb32306dce)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /home/mgorny/git/llvm-project/build/./bin
Configuration file: /tmp/clang-config/x86_64-pc-linux-gnu-clang.cfg

Also note that it performs the arch substitution on this path:

$ ./bin/x86_64-pc-linux-gnu-clang --version -m32
clang version 16.0.0 ([e-mail]:llvm/llvm-project.git 17779984ca4441657071ea5abe6ef2bb32306dce)
Target: i386-pc-linux-gnu
Thread model: posix
InstalledDir: /home/mgorny/git/llvm-project/build/./bin
Configuration file: /tmp/clang-config/i386-pc-linux-gnu-clang.cfg

So your proposal breaks backwards compatibility.

If x86_64-pc-linux-gnu-clang.cfg is found, it is loaded as configuration file and that's all. Otherwise the middle components are dropped and only target prefix and driver mode suffix are used for the search. It is similar to the search made by existing implementation, the following files that are looked for :

• i386-clang.cfg
• i386.cfg
• x86_64-clang.cfg
• x86_64.cfg

If the file found has form target.cfg or none of the files was found, clang tries to load driver-mode configuration file. The files are the same as in your algorithm:

• clang++.cfg
• clang.cfg

The driver-mode configuration is loaded prior to the target config, - as it may contain default settings that target config may override. In the current implementation such files are not, risk of breaking compatibility is minimal.

What do you think about this variant? Does it fit your use case?

Well, my immediate use case only needs per-driver mode configuration files, so it would work — presuming we're using the real driver mode and not the executable suffix.

However, I definitely do see potential use cases for per-target configuration files — for example, providing target-specific paths instead of hardcoding them in the driver. Please note that architecture part alone is insufficient here — there are ABIs (such as n32 ABI on mips or x32 ABI on x86_64) that can only be distinguished by -gnuabin32 or -gnux32 suffix rather than the architecture part. This is also relevant to hardfloat/softfloat targets, and the larger part of the triple is definitely needed for cross-toolchains that may target different operating systems.

Perhaps it would be easier if you described your use case to me — I presume you have one as author of the original patch.

[sepavloff]

In D134337#3813798, @mgorny wrote:

In D134337#3813779, @sepavloff wrote:

First clang tries to find x86_64-pc-linux-gnu-clang.cfg. Just tool name with added suffix cfg. No target override, no attempt to split tool name into components. It provides possibility to have a separate configuration for any tool. The existing mechanism does not search for such file, so compatibility cannot be broken. This variant makes it possible to use configuration file even if tool name is arbitrary and does not follow usual pattern.

That's incorrect. The existing algorithm uses precisely this file if that's how clang is named:

I was wrong, the target prefix reported by ToolChain::getTargetAndModeFromProgramName is everything but the driver component, so indeed the first file tried for configuration is x86_64-pc-linux-gnu-clang.cfg. So the new algorithm would try files tried by current implementation and risk of breaking compatibility would be minimized.

In D134337#3805368, @mgorny wrote:

For target, it will try:

1. i386.cfg (effective triple)
2. i386-pc-linux-gnu.cfg ("fixed" prefix)
3. x86_64-pc-linux-gnu.cfg (orig. prefix)

Does it mean that i386.cfg would be tried before i386-pc-linux-gnu.cfg? It looks more natural to try specific variant first then generic. File x86_64.cfg is not used in this algorithm, what is the reason for this?

[mgorny]

In D134337#3815339, @sepavloff wrote:

In D134337#3805368, @mgorny wrote:

For target, it will try:

1. i386.cfg (effective triple)
2. i386-pc-linux-gnu.cfg ("fixed" prefix)
3. x86_64-pc-linux-gnu.cfg (orig. prefix)

Does it mean that i386.cfg would be tried before i386-pc-linux-gnu.cfg? It looks more natural to try specific variant first then generic. File x86_64.cfg is not used in this algorithm, what is the reason for this?

Yes but this is only because the example explicitly passes -target i386, i.e. incompletely triple. If you passed -target i386-pc-linux-gnu, then it would try that one instead. Perhaps I should try and see what triple normalization does here.

[MaskRay]

In D134337#3815412, @mgorny wrote:

In D134337#3815339, @sepavloff wrote:

In D134337#3805368, @mgorny wrote:

For target, it will try:

1. i386.cfg (effective triple)
2. i386-pc-linux-gnu.cfg ("fixed" prefix)
3. x86_64-pc-linux-gnu.cfg (orig. prefix)

Does it mean that i386.cfg would be tried before i386-pc-linux-gnu.cfg? It looks more natural to try specific variant first then generic. File x86_64.cfg is not used in this algorithm, what is the reason for this?

Yes but this is only because the example explicitly passes -target i386, i.e. incompletely triple. If you passed -target i386-pc-linux-gnu, then it would try that one instead. Perhaps I should try and see what triple normalization does here.

Trying just i386.cfg for x86_64-pc-linux-gnu-clang --target=i386 makes sense to me. Trying x86_64*.cfg seems inappropriate.
I do not recommend i386-pc-linux-gnu.cfg since --target= is as if completely ignoring the executable prefix.

If x86_64-pc-linux-gnu-clang --target=i386-pc-linux-gnu is specified, trying i386-pc-linux-gnu-clang.cfg makes sense. I do not know whether i386-clang.cfg should be tried as well.

[sepavloff]

In D134337#3815705, @MaskRay wrote:

In D134337#3815412, @mgorny wrote:

In D134337#3815339, @sepavloff wrote:

In D134337#3805368, @mgorny wrote:

For target, it will try:

1. i386.cfg (effective triple)
2. i386-pc-linux-gnu.cfg ("fixed" prefix)
3. x86_64-pc-linux-gnu.cfg (orig. prefix)

Does it mean that i386.cfg would be tried before i386-pc-linux-gnu.cfg? It looks more natural to try specific variant first then generic. File x86_64.cfg is not used in this algorithm, what is the reason for this?

Yes but this is only because the example explicitly passes -target i386, i.e. incompletely triple. If you passed -target i386-pc-linux-gnu, then it would try that one instead. Perhaps I should try and see what triple normalization does here.

Trying just i386.cfg for x86_64-pc-linux-gnu-clang --target=i386 makes sense to me. Trying x86_64*.cfg seems inappropriate.
I do not recommend i386-pc-linux-gnu.cfg since --target= is as if completely ignoring the executable prefix.

If x86_64-pc-linux-gnu-clang --target=i386-pc-linux-gnu is specified, trying i386-pc-linux-gnu-clang.cfg makes sense. I do not know whether i386-clang.cfg should be tried as well.

It make sense but the algorithm looks overcomplicated. The current implementation is already too complex and documenting the new algorithm is a challenge.

What about making minimal changes to the current algorithm so that the task of @mgorny can be done, without reasoning about possible profit for someone else? Our customers don't use target overloading and prefixes longer than target, so any change that preserve existing functionality is OK.

A part of this algorithm that loads driver mode configuration is worth implementing:

In D134337#3805368, @mgorny wrote:

For driver, it will try:

1. clang++.cfg (effective mode)
2. clang.cfg (suffix)

It must not break compatibility with existing implementation and allows further extension in future. For more complex use cases driver configuration may implement mode complex syntax as proposed in https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606/41.

@mgorny what modifications to target mode file search are necessary for your task?

[mgorny]

In D134337#3817133, @sepavloff wrote:

It make sense but the algorithm looks overcomplicated. The current implementation is already too complex and documenting the new algorithm is a challenge.

What about making minimal changes to the current algorithm so that the task of @mgorny can be done, without reasoning about possible profit for someone else? Our customers don't use target overloading and prefixes longer than target, so any change that preserve existing functionality is OK.

Do your customers need all of the current functions? Could you perhaps specify the absolutely minimal algorithm you'd need to work, and I'll try to make the implementation as simple as possible.

In D134337#3805368, @mgorny wrote:

For driver, it will try:

1. clang++.cfg (effective mode)
2. clang.cfg (suffix)

It must not break compatibility with existing implementation and allows further extension in future. For more complex use cases driver configuration may implement mode complex syntax as proposed in https://discourse.llvm.org/t/rfc-adding-a-default-file-location-to-config-file-support/63606/41.

@mgorny what modifications to target mode file search are necessary for your task?

For my immediate task, I'm perfectly happy with leaving it as-is, as long as it won't get in the way of getting effective driver mode config in. I'm a bit worried that better target support may be useful in the future but I suppose that ship has sailed already.

[mgorny]

Ok, how about this variant? I think it's the simplest I can come up with that roughly matches the old behavior and adds what's necessary for the new.

The algorithm is to use:

1. <triple>-<mode>.cfg if available, using the real <mode>,
2. <triple>-<mode>.cfg if available, using <mode> inferred from executable name,
3. <triple>.cfg + <mode>.cfg if either is available, using the real <mode>,
4. <triple>.cfg + <mode>.cfg if either is available, using the <mode> inferred from executable.

The important features of this are:

1. Triple accounts for -m32 and other options changing mode, so x86_64-specific configs won't be used when building 32-bit executables.
2. Triple accounts for executable prefix, so the existing configs will continue to work (presuming that your customers do not use --target, as you noted).
3. It accounts both for real mode and mode inferred from executable, so it will prefer the correct config when --driver-mode= is used but it will also work with existing configs that used different executable names.

Unlike the previous mode, there's no potential confusion between 32-bit and 64-bit configs, and the logic is definitely less confusing.

[sepavloff]

In D134337#3817878, @mgorny wrote:

Ok, how about this variant? I think it's the simplest I can come up with that roughly matches the old behavior and adds what's necessary for the new.

The algorithm is to use:

1. <triple>-<mode>.cfg if available, using the real <mode>,
2. <triple>-<mode>.cfg if available, using <mode> inferred from executable name,
3. <triple>.cfg + <mode>.cfg if either is available, using the real <mode>,
4. <triple>.cfg + <mode>.cfg if either is available, using the <mode> inferred from executable.

This algorithm looks good. It is compatible with the existing algorithm if target is not overridden. In the case of overridden target behavior is different, but you a right, using x86_64.cfg in compilation for 32-bit target is not natural. Probably we should document the difference in ReleaseNotes.rst. Also documentation in UserManual.rst should be updated.

[mgorny]

Thanks. Since the algorithm's good, I'll work on updating the docs and tests.

[mgorny]

Update tests. Docs coming up next.

[mgorny]

Added doc update. Would use some help with release notes.

[mgorny]

Adding @thesamesam to reviewers since he's been testing it on Gentoo, and I'd like to get his ACK too.

[mgorny]

Update release notes. I may have been a bit verbose/repeating myself.

[MaskRay]

Thanks. The previous behavior is too magical. I like this version.

clang/docs/ReleaseNotes.rst

252

-target => --target=

avoid legacy spelling

clang/test/Driver/config-file3.c

35

Since %t is rebuilt. You can just use touch

86

Is // FULL1-NOT: Configuration file: sufficient?

92

Is // FULL1-NOT: Configuration file: sufficient?

[pengfei]

clang/test/Driver/config-file3.c

35

touch may not work on Windows?

[mgorny]

clang/docs/ReleaseNotes.rst

252

Ah, so it needs = (I really hate the option parsing in clang, you know?).

BTW that's what got me to use -target:

$ clang --target foo
clang-16: error: unsupported option '--target'; did you mean '-target'?

clang/test/Driver/config-file3.c

35

Well, my experience tells me to avoid external commands when the goal can be achieved via a builtin but touch is more popular in clang indeed.

86

Indeed. I forgot that FileCheck is weird-ish about retrying the matches ;-).

[mgorny]

Use --target= instead of -target. Use touch instead of echo >. Shorten FileCheck matches and guarantee that only expected configs appear.

[MaskRay]

clang/lib/Driver/Driver.cpp

6215

llvm_unreachable

[mgorny]

Use llvm_unreachable().

[sepavloff]

clang/docs/ReleaseNotes.rst

245–248

I would say this paragraph is a combination of two provided below. IMHO.

249

This paragraph is actually about two changes. One is about loading driver mode file, this is an extension. The other is about skipping files using original target prefix. It is potentially breaking change and is worth separate paragraph.

clang/docs/UsersManual.rst

918

I would propose changing <target>-><triple> and target->triple to reduce misunderstanding.

949–950

Maybe target->triple, <target.cfg>-><triplr.cfg>?

966

I think we need to put something like:
It is not an error if any or both of these files are not found.

clang/lib/Driver/Driver.cpp

1110

Can the variable name be better? It looks like it means that driver mode is replaced (overridden).

clang/test/Driver/config-file3.c

35

IIRC, shell is not available on Windows.

[mgorny]

clang/docs/ReleaseNotes.rst

245–248

Yeah, it was intentional. I was thinking it would be cleaner to describe this in tandem but I won't insist. Just please confirm whether I should remove it or keep it.

249

Updated.

clang/lib/Driver/Driver.cpp

1110

Can you suggest a better name? It's used to avoid searching for the same filename twice.

6215

Right, sorry, forgot about it.

[mgorny]

Updated docs per @sepavloff 's suggestions.

[sepavloff]

clang/docs/ReleaseNotes.rst

245–248

No, I don't insist. It is OK.

clang/lib/Driver/Driver.cpp

1110

DriverModeReplaced? Or something like that.

[mgorny]

clang/lib/Driver/Driver.cpp

1110

Ok, how about something more literal? TryModeSuffix.

[mgorny]

Rename the bool to TryModeSuffix.

[sepavloff]

clang/lib/Driver/Driver.cpp

1108

Loading driver-mode config should take place before loading target config, it allows to override default settings set by driver mode config in target config. Also a test is need for such case.

clang/test/Driver/config-file3.c

27

Tests must check the case when target prefix is not a real triple as in the original test (qqq-clang).

98

We also need a test that checks that in the case of --target=i386-unknown-linux-gnu and absence of i386-unknown-linux-gnu-clang++.cfg clang does not load x86_64-unknown-linux-gnu-clang-g++.cfg.

238–240

target and driver mode configs should be in reverse order.

[arichardson]

clang/test/Driver/config-file3.c

27

It would be quite important for me that this continues to work. I made use of that in the CheriBSD toolchain when creating symlinked binaries to easily build for different ABIs such as cheribsd-riscv64-hybrid-clang++ and cheribsd-riscv64-purecap-clang-cpp. It appears this previously only worked if the prefix did not start with a valid triple (which is why I put the OS before the architecture). I think it would also be nice if the whole prefix was checked even if it starts with a valid triple, but this does not need to be changed in this patch (haven't looked at it in detail so this might actually work).

[mgorny]

clang/lib/Driver/Driver.cpp

1108

Do you have any specific option in mind? The main idea was that you use full triple+driver config when you need overrides because — as we pretty much established before — the options accepted by different drivers are too different for them to be meaningfully used with a single config file shared between targets.

clang/test/Driver/config-file3.c

27

If the prefix is not a valid triple, then clang ignores it and uses host triple instead. And now we're back to square one. If I check both variants, it's too complex. If I don't, it's bad too.

[sepavloff]

clang/lib/Driver/Driver.cpp

1108

I mean we can have several driver-mode configs like tool.cfg, where some default settings are set (maybe by using @file constructs`) and several target.cfg which may override options defined in tool.cfg. Due to different target and driver configs loaded separately, we can avoid creating separate config for each target+driver combination. Not a killer feature, but it is convenient.

As I understand, it is enough to swap code that tries loading driver config below with this piece of code, no?

clang/test/Driver/config-file3.c

27

Our customers use this feature. Target prefix may designate, for example, debug build or build with specific framework.

[mgorny]

clang/test/Driver/config-file3.c

27

How are we supposed to avoid the "absurd" case where x86_64 configs are loaded for -m32 invocation then?

[sepavloff]

clang/test/Driver/config-file3.c

27

In this case overloading target does not makes sense. You need to analyze RealTriple in Driver::loadDefaultConfigFiles and if it is wrong, use target prefix as if it is real target.

[mgorny]

clang/test/Driver/config-file3.c

27

What do you mean by "wrong"? The target triple is always a correct triple.

[sepavloff]

clang/test/Driver/config-file3.c

27

Not triple, sorry. Target prefix taken from ClangNameParts.TargetPrefix.

[mgorny]

clang/test/Driver/config-file3.c

27

Now I'm confused. Are you suggesting that we use prefix instead of target if it's… incorrect?

[sepavloff]

clang/test/Driver/config-file3.c

27

Basically yes.

We need to support arbitrary target prefixes, because they are used now. If ClangNameParts.TargetPrefix is not a valid triple, use it to build config file names.

We also need to use config files like x86_64.cfg where middle components are dropped, they are also used. They also need to support target overloading.

[mgorny]

Swap driver and target config loading order.

[arichardson]

clang/test/Driver/config-file3.c

27

I can replace my approach with simple shell scripts that invoke clang --config=..., but IMO it would be nice if the logic was something like the first check being
if "explicit --target empty" and "ClangNameParts.TargetPrefix non-empty" and "ClangNameParts.TargetPrefix not a valid triple" -> load ClangNameParts.TargetPrefix + ".cfg" followed by the current logic.
I don't mind either way whether the first check should also load a driver-specific config file or not. I'd also be happy if the logic was "try loading ClangNameParts.TargetPrefix if explicit --target empty" regardless of whether it is a valid triple or not.
Does this approach sound reasonable?

[mgorny]

clang/test/Driver/config-file3.c

27

Ok, so I guess that the logic would be: if name prefix's (non-normalized) triple does not have valid arch or valid os parts, we use that instead of real triple.

98

Isn't this what FULL2 + -m32 tests for?

[mgorny]

Implement the backwards compatible logic for using name prefix if 1) no target override options are used, and 2) name prefix is not a valid triple.

[mgorny]

@sepavloff, @arichardson, does this approach look OK? I've included the cheribsd name in tests.

[sepavloff]

LGTM.

Thanks!

[MaskRay]

clang/include/clang/Driver/Driver.h

761

This should be private

clang/lib/Driver/Driver.cpp

1098

"executable suffix" is less clear. An example will help.

1105

Mention "first part" ? (And what does "first part refer to")

[mgorny]

Address @MaskRay 's comments.

clang/include/clang/Driver/Driver.h

761

No opinion but will do.

clang/lib/Driver/Driver.cpp

1098

Added for *clang-g++ below. Hope that's good enough.

1105

I don't understand this comment.

[MaskRay]

clang/lib/Driver/Driver.cpp

1074–1089

The next common mentions "second part" but it isn't very clear what "first part" and "second part" mean.
Perhaps repeat <triple>.cfg here and replace "second part" with "<mode>.cfg"

[mgorny]

clang/lib/Driver/Driver.cpp

1074–1089

Oh, it's so weird because the comment was moved when I was swapping the logic but didn't notice it needs to be updated.

[mgorny]

Change confusing comments.

[MaskRay]

clang/test/Driver/config-file3.c

176–180

This pattern can be replaced with FileCheck's --implicit-check-not='Configuration file:'

[nickdesaulniers]

It might be nice to work with rustc folks on the format of these configs. A frequent difficulty between Rust and C interop is the totally different command line flags necessary to compile code meant to link together and match as much of the ABI as possible.

[ojeda]

Thanks Nick for the ping. Indeed, rustc allows to use a "target specification file" to create new targets that are not built-in, as a JSON file.

They are unstable though, since they are fairly tied to LLVM, and I think the Rust compiler team prefers to stabilize flags instead.

However, it would definitely be great for users and build systems if GCC, Clang and rustc could get together and decide on a new, common config file, even if it just covered the target specification.

[MaskRay]

In D134337#3824683, @ojeda wrote:

Thanks Nick for the ping. Indeed, rustc allows to use a "target specification file" to create new targets that are not built-in, as a JSON file.

They are unstable though, since they are fairly tied to LLVM, and I think the Rust compiler team prefers to stabilize flags instead.

However, it would definitely be great for users and build systems if GCC, Clang and rustc could get together and decide on a new, common config file, even if it just covered the target specification.

Clang just uses a plain text file similar to a response file (which one can specify with clang ... @a.rsp before Clang got --config support).
It's unclear Clang wants to support GCC style specs file and whether GCC wants to adopt another system beside its specs.
I lean toward there isn't much cooperation as we might think.

[mgorny]

clang/test/Driver/config-file3.c

176–180

Thanks. I've only read your comment after pushing but I've done that now, and it is a definite improvement:

[main 78c97b46e6e0] [clang] [test] Use --implicit-check-not in config-file3 tests
 Date: Fri Sep 30 07:59:41 2022 +0200
 1 file changed, 26 insertions(+), 68 deletions(-)

[nickdesaulniers]

In D134337#3824862, @MaskRay wrote:

It's unclear Clang wants to support GCC style specs file and whether GCC wants to adopt another system beside its specs.
I lean toward there isn't much cooperation as we might think.

Perhaps there ought to be?

[MaskRay]

In D134337#3827522, @nickdesaulniers wrote:

In D134337#3824862, @MaskRay wrote:

It's unclear Clang wants to support GCC style specs file and whether GCC wants to adopt another system beside its specs.
I lean toward there isn't much cooperation as we might think.

Perhaps there ought to be?

rust use very different compiler options from Clang/GCC, so it's clear what benefits a unified format can bring, if we consider that more established compilers want to prefer internal consistency and avoid introducing duplicate mechanism.
GCC uses specs files. There may be some obstacles introducing a new mechanism.
Clang Driver doesn't support specs files. We pick configuration files for now whose format isn't different from the traditional response files.

If anything, rust can make a decision to support Clang style configuration files.

[tstellar]

clang/docs/UsersManual.rst

954

Is x86_64-pc-linux-gnu-clang-g++ being passed to --driver= in this example?

[tstellar]

In what scenarios will clang load the clang.cfg file?

[mgorny]

In D134337#3863744, @tstellar wrote:

In what scenarios will clang load the clang.cfg file?

It will load it if all of the following are true:

1. --no-default-config is not passed.
2. a more specific <triple>-clang.cfg is not found.
3. --driver-mode=gcc is in effect or the executable is named clang or *-clang and --driver-mode= did not select another config file.

clang/docs/UsersManual.rst

954

I don't understand your question. x86_64-pc-linux-gnu-clang-g++ is the executable (symlink) name here.

[tstellar]

In D134337#3864288, @mgorny wrote:

In D134337#3863744, @tstellar wrote:

In what scenarios will clang load the clang.cfg file?

It will load it if all of the following are true:

1. --no-default-config is not passed.
2. a more specific <triple>-clang.cfg is not found.
3. --driver-mode=gcc is in effect or the executable is named clang or *-clang and --driver-mode= did not select another config file.

I know I'm a little late here, but having a default config file that's always loaded makes triaging issues much harder, because now every time someone files a bug, we need to ask for the contents of their config directory.

clang/docs/UsersManual.rst

954

OK, it's a symlink. That makes sense.

[mgorny]

In D134337#3865541, @tstellar wrote:

I know I'm a little late here, but having a default config file that's always loaded makes triaging issues much harder, because now every time someone files a bug, we need to ask for the contents of their config directory.

I don't see that as much worse than asking them for the values of *DEFAULT* CMake options or whether they have patched their clang because the driver code makes so many specific assumptions that it didn't work for them. At least clang -v tells us whether they are actually using any configs.

[tstellar]

In D134337#3865753, @mgorny wrote:

In D134337#3865541, @tstellar wrote:

I know I'm a little late here, but having a default config file that's always loaded makes triaging issues much harder, because now every time someone files a bug, we need to ask for the contents of their config directory.

I don't see that as much worse than asking them for the values of *DEFAULT* CMake options or whether they have patched their clang because the driver code makes so many specific assumptions that it didn't work for them. At least clang -v tells us whether they are actually using any configs.

At least as a distro maintainer, I know the CMake options used for the packages I'm trying to support.

I was also wondering, would it be possible to move some of the targets specific driver code out of the codebase and into config files that are shipped with clang?

[thesamesam]

In D134337#3865905, @tstellar wrote:

In D134337#3865753, @mgorny wrote:

In D134337#3865541, @tstellar wrote:

I know I'm a little late here, but having a default config file that's always loaded makes triaging issues much harder, because now every time someone files a bug, we need to ask for the contents of their config directory.

I don't see that as much worse than asking them for the values of *DEFAULT* CMake options or whether they have patched their clang because the driver code makes so many specific assumptions that it didn't work for them. At least clang -v tells us whether they are actually using any configs.

At least as a distro maintainer, I know the CMake options used for the packages I'm trying to support.

I was also wondering, would it be possible to move some of the targets specific driver code out of the codebase and into config files that are shipped with clang?

We covered the need for this, I feel, quite extensively in the linked discussions - especially wrt the Clang 15/16 -Werror changes.

As for bug reports: just ask people to use --no-default-config if something looks dodgy?

[mgorny]

In D134337#3865905, @tstellar wrote:

In D134337#3865753, @mgorny wrote:

In D134337#3865541, @tstellar wrote:

I know I'm a little late here, but having a default config file that's always loaded makes triaging issues much harder, because now every time someone files a bug, we need to ask for the contents of their config directory.

I don't see that as much worse than asking them for the values of *DEFAULT* CMake options or whether they have patched their clang because the driver code makes so many specific assumptions that it didn't work for them. At least clang -v tells us whether they are actually using any configs.

At least as a distro maintainer, I know the CMake options used for the packages I'm trying to support.

As a distro maintainer, you can decide to build clang without system/user config directories set (which is the default), in which case only explicit --config will work.

[sepavloff]

In D134337#3866267, @mgorny wrote:

In D134337#3865905, @tstellar wrote:

In D134337#3865753, @mgorny wrote:

In D134337#3865541, @tstellar wrote:

I know I'm a little late here, but having a default config file that's always loaded makes triaging issues much harder, because now every time someone files a bug, we need to ask for the contents of their config directory.

I don't see that as much worse than asking them for the values of *DEFAULT* CMake options or whether they have patched their clang because the driver code makes so many specific assumptions that it didn't work for them. At least clang -v tells us whether they are actually using any configs.

At least as a distro maintainer, I know the CMake options used for the packages I'm trying to support.

As a distro maintainer, you can decide to build clang without system/user config directories set (which is the default), in which case only explicit --config will work.

Strictly speaking in this case the default config file may be loaded from the binary directory but the latter is controlled by distro.

Users also may split configuration file into pieces and include them using @file construct, in this case single config file is not enough. I think clang could print driver options in output of -v. Another way is to implement a special command line option, say -print-args, which would print all driver options.

[Arfrever]

After reading this discussion, I need some clarification.

If there were the following symlinks pointing to clang: i386-pc-linux-gnu-clang, i486-pc-linux-gnu-clang, i586-pc-linux-gnu-clang, i686-pc-linux-gnu-clang, x86_64-pc-linux-gnu-clang.
Then do I assume correctly that:

1. x86_64-pc-linux-gnu-clang -m32 would try to load i386.cfg
2. i386-pc-linux-gnu-clang would try to load i386.cfg
3. i486-pc-linux-gnu-clang would try to load i486.cfg
4. i586-pc-linux-gnu-clang would try to load i586.cfg
5. i686-pc-linux-gnu-clang would try to load i686.cfg

?

In modern multilib x86_64 systems, only i686-pc-linux-gnu-clang and x86_64-pc-linux-gnu-clang symlinks (from above list) are likely to exist, but discrepancy in behavior between x86_64-pc-linux-gnu-clang -m32 and i686-pc-linux-gnu-clang will cause confusion of users...

clang/docs/ReleaseNotes.rst

- When using header modules, inclusion of a private header and violations of
   <https://clang.llvm.org/docs/Modules.html#use-declaration>`_ are now
   diagnosed even when the includer is a textual header. This change can be
   temporarily reversed with ``-Xclang
   -fno-modules-validate-textual-header-includes``, but this flag will be
   removed in a future Clang release.
 - Unicode support has been updated to support Unicode 15.0.
   New unicode codepoints are supported as appropriate in diagnostics,
   C and C++ identifiers, and escape sequences.
+- Clang now supports loading multiple configuration files. The files from
+  default configuration paths are loaded first, unless ``--no-default-config``
+  option is used. All files explicitly specified using ``--config=`` option
+  are loaded afterwards.
+- When loading default configuration files, clang now unconditionally uses
+  the real target triple (respecting options such as ``--target=`` and ``-m32``)
+  rather than the executable prefix. The respective configuration files are
+  also loaded when clang is called via an executable without a prefix (e.g.
+  plain ``clang``).
+- Default configuration paths were partially changed. Clang now attempts to load
+  ``<triple>-<driver>.cfg`` first, and falls back to loading both
+  ``<driver>.cfg`` and ``<triple>.cfg`` if the former is not found. `Triple`
+  is the target triple and `driver` first tries the canonical name
+  for the driver (respecting ``--driver-mode=``), and then the name found
+  in the executable.
 
 New Compiler Flags
 ------------------
 
 - Implemented `-fcoro-aligned-allocation` flag. This flag implements
   Option 2 of P2014R0 aligned allocation of coroutine frames
   (`P2014R0 <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2014r0.pdf>`_).
   With this flag, the coroutines will try to lookup aligned allocation
   function all the time. The compiler will emit an error if it fails to
   find aligned allocation function. So if the user code implemented self
   defined allocation function for coroutines, the existing code will be
   broken. A little divergence with P2014R0 is that clang will lookup
   `::operator new(size_­t, std::aligned_val_t, nothrow_­t)` if there is
   `get_­return_­object_­on_­allocation_­failure`. We feel this is more consistent
   with the intention.
+- Added ``--no-default-config`` to disable automatically loading configuration
+  files using default paths.
 
 Deprecated Compiler Flags
 -------------------------
 
 Modified Compiler Flags
 -----------------------
+- Clang now permits specifying ``--config=`` multiple times, to load multiple
+  configuration files.
 
 Removed Compiler Flags
 -------------------------
 
 New Pragmas in Clang
 --------------------
 - ...
 

clang/docs/UsersManual.rst

 ``CLANG_CONFIG_FILE_SYSTEM_DIR`` respectively. The first file found is used.
 It is an error if the required file cannot be found.
 
 The default configuration files are searched for in the same directories
 following the rules described in the next paragraphs. Loading default
 configuration files can be disabled entirely via passing
 the ``--no-default-config`` flag.
 
-The name of the default configuration file is deduced from the clang executable
-name.  For example, if the Clang executable is named ``armv7l-clang`` (it may
-be a symbolic link to ``clang``), then Clang will search for file
-``armv7l.cfg`` in the directory where Clang resides.
-
-If a driver mode is specified in invocation, Clang tries to find a file specific
-for the specified mode. For example, if the executable file is named
-``x86_64-clang-cl``, Clang first looks for ``x86_64-clang-cl.cfg`` and if it is
-not found, looks for ``x86_64.cfg``.
-
-If the command line contains options that effectively change target architecture
-(these are ``-m32``, ``-EL``, and some others) and the configuration file starts
-with an architecture name, Clang tries to load the configuration file for the
-effective architecture. For example, invocation:
+First, the algorithm searches for a configuration file named
+``<triple>-<driver>.cfg`` where `triple` is the triple for the target being
+built for, and `driver` is the name of the currently used driver. The algorithm
+first attempts to use the canonical name for the driver used, then falls back
+to the one found in the executable name.
 
-::
+The following canonical driver names are used:
+
+- ``clang`` for the ``gcc`` driver (used to compile C programs)
+- ``clang++`` for the ``gxx`` driver (used to compile C++ programs)
+- ``clang-cpp`` for the ``cpp`` driver (pure preprocessor)
+- ``clang-cl`` for the ``cl`` driver
+- ``flang`` for the ``flang`` driver
+- ``clang-dxc`` for the ``dxc`` driver
+
+For example, when calling ``x86_64-pc-linux-gnu-clang-g++``,
+the driver will first attempt to use the configuration file named::
+
+    x86_64-pc-linux-gnu-clang++.cfg
+
+If this file is not found, it will attempt to use the name found
+in the executable instead::
+
+    x86_64-pc-linux-gnu-clang-g++.cfg
+
+Note that options such as ``--driver-mode=``, ``--target=``, ``-m32`` affect
+the search algorithm. For example, the aforementioned executable called with
+``-m32`` argument will instead search for::
+
+    i386-pc-linux-gnu-clang++.cfg
+
+If none of the aforementioned files are found, the driver will instead search
+for separate driver and target configuration files and attempt to load both.
+The former is named ``<driver>.cfg`` while the latter is named
+``<triple>.cfg``. Similarly to the previous variants, the canonical driver name
+will be preferred, and the compiler will fall back to the actual name.
+
+For example, ``x86_64-pc-linux-gnu-clang-g++`` will attempt to load two
+configuration files named respectively::
+
+    clang++.cfg
+    x86_64-pc-linux-gnu.cfg
+
+with fallback to trying::
 
-    x86_64-clang -m32 abc.c
+    clang-g++.cfg
+    x86_64-pc-linux-gnu.cfg
 
-causes Clang search for a file ``i368.cfg`` first, and if no such file is found,
-Clang looks for the file ``x86_64.cfg``.
+It is not an error if either of these files is not found.
 
 The configuration file consists of command-line options specified on one or
 more lines. Lines composed of whitespace characters only are ignored as well as
 lines in which the first non-blank character is ``#``. Long options may be split
 between several lines by a trailing backslash. Here is example of a
 configuration file:
 
 ::
 

clang/include/clang/Driver/Driver.h

private:
   /// building jobs for the Action's inputs.
   InputInfoList 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>, InputInfoList>
           &CachedResults,
       Action::OffloadKind TargetDeviceOffloadKind) const;
 
+  /// Return the typical executable name for the specified driver \p Mode.
+  static const char *getExecutableForDriverMode(DriverMode Mode);
+
 public:
   /// GetReleaseVersion - Parse (([0-9]+)(.([0-9]+)(.([0-9]+)?))?)? and
   /// return the grouped values as integers. Numbers which are not
   /// provided are set to 0.
   ///
   /// \return True if the entire string was parsed (9.2), or all
   /// groups were parsed (10.3.5extrastuff). HadExtra is true if all
   /// groups were parsed but extra characters remain at the end.
   static bool GetReleaseVersion(StringRef Str, unsigned &Major, unsigned &Minor,
                                 unsigned &Micro, bool &HadExtra);
 
   /// Parse digits from a string \p Str and fulfill \p Digits with
   /// the parsed numbers. This method assumes that the max number of
   /// digits to look for is equal to Digits.size().
   ///
   /// \return True if the entire string was parsed and there are
   /// no extra characters remaining at the end.
   static bool GetReleaseVersion(StringRef Str,
                                 MutableArrayRef<unsigned> Digits);
   /// Compute the default -fmodule-cache-path.
   /// \return True if the system provides a default cache directory.
   static bool getDefaultModuleCachePath(SmallVectorImpl<char> &Result);
 };
 
 /// \return True if the last defined optimization level is -Ofast.
 /// And False otherwise.
 bool isOptimizationLevelFast(const llvm::opt::ArgList &Args);
 
 /// \return True if the argument combination will end up generating remarks.
 bool willEmitRemarks(const llvm::opt::ArgList &Args);
 
 /// Returns the driver mode option's value, i.e. `X` in `--driver-mode=X`. If \p
 /// Args doesn't mention one explicitly, tries to deduce from `ProgName`.

clang/lib/Driver/Driver.cpp

bool Driver::loadConfigFiles() {
 
   // No error occurred.
   return false;
 }
 
 bool Driver::loadDefaultConfigFiles(ArrayRef<StringRef> CfgFileSearchDirs) {
   if (CLOptions && CLOptions->hasArg(options::OPT_no_default_config))
     return false;
-  if (ClangNameParts.TargetPrefix.empty())
-    return false;
 
-  // If config file is not specified explicitly, try to deduce configuration
-  // from executable name. For instance, an executable 'armv7l-clang' will
-  // search for config file 'armv7l-clang.cfg'.
-  std::string CfgFileName =
-        ClangNameParts.TargetPrefix + '-' + ClangNameParts.ModeSuffix;
-
-  // Determine architecture part of the file name, if it is present.
-  StringRef CfgFileArch = CfgFileName;
-  size_t ArchPrefixLen = CfgFileArch.find('-');
-  if (ArchPrefixLen == StringRef::npos)
-    ArchPrefixLen = CfgFileArch.size();
-  llvm::Triple CfgTriple;
-  CfgFileArch = CfgFileArch.take_front(ArchPrefixLen);
-  CfgTriple = llvm::Triple(llvm::Triple::normalize(CfgFileArch));
-  if (CfgTriple.getArch() == llvm::Triple::ArchType::UnknownArch)
-    ArchPrefixLen = 0;
-
-  if (!StringRef(CfgFileName).endswith(".cfg"))
-    CfgFileName += ".cfg";
-
-  // If config file starts with architecture name and command line options
-  // redefine architecture (with options like -m32 -LE etc), try finding new
-  // config file with that architecture.
-  SmallString<128> FixedConfigFile;
-  size_t FixedArchPrefixLen = 0;
-  if (ArchPrefixLen) {
-    // Get architecture name from config file name like 'i386.cfg' or
-    // 'armv7l-clang.cfg'.
-    // Check if command line options changes effective triple.
-    llvm::Triple EffectiveTriple =
-        computeTargetTriple(*this, CfgTriple.getTriple(), *CLOptions);
-    if (CfgTriple.getArch() != EffectiveTriple.getArch()) {
-      FixedConfigFile = EffectiveTriple.getArchName();
-      FixedArchPrefixLen = FixedConfigFile.size();
-      // Append the rest of original file name so that file name transforms
-      // like: i386-clang.cfg -> x86_64-clang.cfg.
-      if (ArchPrefixLen < CfgFileName.size())
-        FixedConfigFile += CfgFileName.substr(ArchPrefixLen);
-    }
-  }
+  std::string RealMode = getExecutableForDriverMode(Mode);
+  std::string Triple;
 
-  // Try to find config file. First try file with corrected architecture.
+  // If name prefix is present, no --target= override was passed via CLOptions
+  // and the name prefix is not a valid triple, force it for backwards
+  // compatibility.
+  if (!ClangNameParts.TargetPrefix.empty() &&
+      computeTargetTriple(*this, "/invalid/", *CLOptions).str() ==
+          "/invalid/") {
+    llvm::Triple PrefixTriple{ClangNameParts.TargetPrefix};
+    if (PrefixTriple.getArch() == llvm::Triple::UnknownArch ||
+        PrefixTriple.isOSUnknown())
+      Triple = PrefixTriple.str();
+  }
+
+  // Otherwise, use the real triple as used by the driver.
+  if (Triple.empty()) {
+    llvm::Triple RealTriple =
+        computeTargetTriple(*this, TargetTriple, *CLOptions);
+    Triple = RealTriple.str();
+    assert(!Triple.empty());
+  }
+
+  // Search for config files in the following order:
+  // 1. <triple>-<mode>.cfg using real driver mode
+  //    (e.g. i386-pc-linux-gnu-clang++.cfg).
+  // 2. <triple>-<mode>.cfg using executable suffix
+  //    (e.g. i386-pc-linux-gnu-clang-g++.cfg for *clang-g++).
+  // 3. <triple>.cfg + <mode>.cfg using real driver mode
+  //    (e.g. i386-pc-linux-gnu.cfg + clang++.cfg).
+  // 4. <triple>.cfg + <mode>.cfg using executable suffix
+  //    (e.g. i386-pc-linux-gnu.cfg + clang-g++.cfg for *clang-g++).
+
+  // Try loading <triple>-<mode>.cfg, and return if we find a match.
   llvm::SmallString<128> CfgFilePath;
-  if (!FixedConfigFile.empty()) {
-    if (searchForFile(CfgFilePath, CfgFileSearchDirs, FixedConfigFile,
-                      getVFS()))
-      return readConfigFile(CfgFilePath);
-    // If 'x86_64-clang.cfg' was not found, try 'x86_64.cfg'.
-    FixedConfigFile.resize(FixedArchPrefixLen);
-    FixedConfigFile.append(".cfg");
-    if (searchForFile(CfgFilePath, CfgFileSearchDirs, FixedConfigFile,
-                      getVFS()))
-      return readConfigFile(CfgFilePath);
-  }
+  std::string CfgFileName = Triple + '-' + RealMode + ".cfg";
+  if (searchForFile(CfgFilePath, CfgFileSearchDirs, CfgFileName, getVFS()))
 
-  // Then try original file name.
+  bool TryModeSuffix = !ClangNameParts.ModeSuffix.empty() &&
+                       ClangNameParts.ModeSuffix != RealMode;
+  if (TryModeSuffix) {
+    CfgFileName = Triple + '-' + ClangNameParts.ModeSuffix + ".cfg";
     if (searchForFile(CfgFilePath, CfgFileSearchDirs, CfgFileName, getVFS()))
       return readConfigFile(CfgFilePath);
+  }
+
+  // Try loading <mode>.cfg, and return if loading failed.  If a matching file
+  // was not found, still proceed on to try <triple>.cfg.
+  CfgFileName = RealMode + ".cfg";
+  if (searchForFile(CfgFilePath, CfgFileSearchDirs, CfgFileName, getVFS())) {
+    if (readConfigFile(CfgFilePath))
+      return true;
+  } else if (TryModeSuffix) {
+    CfgFileName = ClangNameParts.ModeSuffix + ".cfg";
+    if (searchForFile(CfgFilePath, CfgFileSearchDirs, CfgFileName, getVFS()) &&
+        readConfigFile(CfgFilePath))
+      return true;
+  }
 
-  // Finally try removing driver mode part: 'x86_64-clang.cfg' -> 'x86_64.cfg'.
-  if (!ClangNameParts.ModeSuffix.empty() &&
-      !ClangNameParts.TargetPrefix.empty()) {
-    CfgFileName.assign(ClangNameParts.TargetPrefix);
-    CfgFileName.append(".cfg");
-    if (searchForFile(CfgFilePath, CfgFileSearchDirs, CfgFileName, getVFS()))
-      return readConfigFile(CfgFilePath);
-  }
+  // Try loading <triple>.cfg and return if we find a match.
+  CfgFileName = Triple + ".cfg";
 
   // If we were unable to find a config file deduced from executable name,
-  // do not report an error.
+  // that is not an error.
   return false;
 }
 
 Compilation *Driver::BuildCompilation(ArrayRef<const char *> ArgList) {
   llvm::PrettyStackTraceString CrashInfo("Compilation construction");
 
   // FIXME: Handle environment options which affect driver behavior, somewhere
   // (client?). GCC_EXEC_PREFIX, LPATH, CC_PRINT_OPTIONS.
if (IsDXCMode()) {
     ExcludedFlagsBitmask |= options::DXCOption;
   }
   if (!IsClCompatMode && !IsDXCMode())
     ExcludedFlagsBitmask |= options::CLDXCOption;
 
   return std::make_pair(IncludedFlagsBitmask, ExcludedFlagsBitmask);
 }
 
+const char *Driver::getExecutableForDriverMode(DriverMode Mode) {
+  switch (Mode) {
+  case GCCMode:
+    return "clang";
+  case GXXMode:
+    return "clang++";
+  case CPPMode:
+    return "clang-cpp";
+  case CLMode:
+    return "clang-cl";
+  case FlangMode:
+    return "flang";
+  case DXCMode:
+    return "clang-dxc";
+  }
+
+  llvm_unreachable("Unhandled Mode");
+}
+
 bool clang::driver::isOptimizationLevelFast(const ArgList &Args) {
   return Args.hasFlag(options::OPT_Ofast, options::OPT_O_Group, false);
 }
 
 bool clang::driver::willEmitRemarks(const ArgList &Args) {
   // -fsave-optimization-record enables it.
   if (Args.hasFlag(options::OPT_fsave_optimization_record,
                    options::OPT_fno_save_optimization_record, false))

clang/test/Driver/config-file3.c

 // REQUIRES: shell
 // REQUIRES: x86-registered-target
 
 // RUN: rm -rf %t && mkdir %t
 
 //--- If config file is specified by relative path (workdir/cfg-s2), it is searched for by that path.
 
 // RUN: mkdir -p %t/workdir/subdir
 // RUN: echo "@subdir/cfg-s2" > %t/workdir/cfg-1
 // RUN: echo "-Wundefined-var-template" > %t/workdir/subdir/cfg-s2
 //
-// RUN: ( cd %t && %clang --config workdir/cfg-1 -c -### %s 2>&1 | FileCheck %s -check-prefix CHECK-REL )
+// RUN: ( cd %t && %clang --config=workdir/cfg-1 -c -### %s 2>&1 | FileCheck %s -check-prefix CHECK-REL )
 //
 // CHECK-REL: Configuration file: {{.*}}/workdir/cfg-1
 // CHECK-REL: -Wundefined-var-template
 
+//--- Config files are searched for in binary directory as well.
+//
+// RUN: mkdir %t/testbin
+// RUN: ln -s %clang %t/testbin/clang
+// RUN: echo "-Werror" > %t/testbin/aaa.cfg
+// RUN: %t/testbin/clang --config-system-dir= --config-user-dir= --config=aaa.cfg -c -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-BIN
+//
+// CHECK-BIN: Configuration file: {{.*}}/testbin/aaa.cfg
+// CHECK-BIN: -Werror
 
-//--- Invocation qqq-clang-g++ tries to find config file qqq-clang-g++.cfg first.
+//--- Invocation x86_64-unknown-linux-gnu-clang-g++ tries x86_64-unknown-linux-gnu-clang++.cfg first.
 //
 // RUN: mkdir %t/testdmode
+// RUN: ln -s %clang %t/testdmode/cheribsd-riscv64-hybrid-clang++
 // RUN: ln -s %clang %t/testdmode/qqq-clang-g++
-// RUN: echo "-Wundefined-func-template" > %t/testdmode/qqq-clang-g++.cfg
-// RUN: echo "-Werror" > %t/testdmode/qqq.cfg
-// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir= --config-user-dir= -c -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix FULL-NAME
+// RUN: ln -s %clang %t/testdmode/x86_64-clang
+// RUN: ln -s %clang %t/testdmode/i386-unknown-linux-gnu-clang-g++
+// RUN: ln -s %clang %t/testdmode/x86_64-unknown-linux-gnu-clang-g++
+// RUN: ln -s %clang %t/testdmode/x86_64-unknown-linux-gnu-clang
+// RUN: touch %t/testdmode/cheribsd-riscv64-hybrid-clang++.cfg
+// RUN: touch %t/testdmode/cheribsd-riscv64-hybrid.cfg
+// RUN: touch %t/testdmode/qqq-clang-g++.cfg
+// RUN: touch %t/testdmode/qqq.cfg
+// RUN: touch %t/testdmode/x86_64-clang.cfg
+// RUN: touch %t/testdmode/x86_64.cfg
+// RUN: touch %t/testdmode/x86_64-unknown-linux-gnu-clang++.cfg
+// RUN: touch %t/testdmode/x86_64-unknown-linux-gnu-clang-g++.cfg
+// RUN: touch %t/testdmode/x86_64-unknown-linux-gnu-clang.cfg
+// RUN: touch %t/testdmode/x86_64-unknown-linux-gnu.cfg
+// RUN: touch %t/testdmode/i386-unknown-linux-gnu-clang++.cfg
+// RUN: touch %t/testdmode/i386-unknown-linux-gnu-clang-g++.cfg
+// RUN: touch %t/testdmode/i386-unknown-linux-gnu-clang.cfg
+// RUN: touch %t/testdmode/i386-unknown-linux-gnu.cfg
+// RUN: touch %t/testdmode/clang++.cfg
+// RUN: touch %t/testdmode/clang-g++.cfg
+// RUN: touch %t/testdmode/clang.cfg
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1
+//
+// FULL1-NOT: Configuration file:
+// FULL1: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu-clang++.cfg
+// FULL1-NOT: Configuration file:
+
+//--- -m32 overrides triple.
+//
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ -m32 --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1-I386
+//
+// FULL1-I386-NOT: Configuration file:
+// FULL1-I386: Configuration file: {{.*}}/testdmode/i386-unknown-linux-gnu-clang++.cfg
+// FULL1-I386-NOT: Configuration file:
+
+//--- --target= also works for overriding triple.
+//
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --target=i386-unknown-linux-gnu --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1-I386
+
+//--- With --target= + -m64, -m64 takes precedence.
+//
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --target=i386-unknown-linux-gnu -m64 --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1
+
+//--- i386 prefix also works for 32-bit.
+//
+// RUN: %t/testdmode/i386-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1-I386
+
+//--- i386 prefix + -m64 also works for 64-bit.
+//
+// RUN: %t/testdmode/i386-unknown-linux-gnu-clang-g++ -m64 --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1
+
+//--- File specified by --config= is loaded after the one inferred from the executable.
 //
-// FULL-NAME: Configuration file: {{.*}}/testdmode/qqq-clang-g++.cfg
-// FULL-NAME: -Wundefined-func-template
-// FULL-NAME-NOT: -Werror
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir=%S/Inputs/config --config-user-dir= --config=i386-qqq.cfg -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix EXPLICIT
 //
-//--- Invocation qqq-clang-g++ tries to find config file qqq-clang-g++.cfg even without -no-canonical-prefixes.
-// (As the clang executable and symlink are in different directories, this
-// requires specifying the path via --config-*-dir= though.)
+// EXPLICIT: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu-clang++.cfg
+// EXPLICIT-NEXT: Configuration file: {{.*}}/Inputs/config/i386-qqq.cfg
+
+//--- --no-default-config --config= loads only specified file.
 //
-// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir= --config-user-dir=%t/testdmode -c -### %s 2>&1 | FileCheck %s -check-prefix SYMLINK
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir=%S/Inputs/config --config-user-dir= --no-default-config --config=i386-qqq.cfg -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix EXPLICIT-ONLY
 //
-// SYMLINK: Configuration file: {{.*}}/testdmode/qqq-clang-g++.cfg
+// EXPLICIT-ONLY-NOT: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu-clang++.cfg
+// EXPLICIT-ONLY: Configuration file: {{.*}}/Inputs/config/i386-qqq.cfg
 
-//--- File specified by --config is loaded after the one inferred from the executable.
+//--- --no-default-config disables default filenames.
 //
-// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir=%S/Inputs/config --config-user-dir= --config i386-qqq.cfg -c -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-EXPLICIT
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir=%S/Inputs/config --config-user-dir= --no-default-config -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix NO-CONFIG
 //
-// CHECK-EXPLICIT: Configuration file: {{.*}}/testdmode/qqq-clang-g++.cfg
-// CHECK-EXPLICIT-NEXT: Configuration file: {{.*}}/Inputs/config/i386-qqq.cfg
+// NO-CONFIG-NOT: Configuration file:
 
-//--- --no-default-config disables config search.
+//--- --driver-mode= is respected.
+//
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --driver-mode=gcc --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1-GCC
 //
-// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir= --config-user-dir=%t/testdmode --no-default-config -c -### %s 2>&1 | FileCheck %s -check-prefix NO-DEFAULT-CONFIG
+// FULL1-GCC-NOT: Configuration file:
+// FULL1-GCC: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu-clang.cfg
+// FULL1-GCC-NOT: Configuration file:
+
+//--- "clang" driver symlink should yield the "*-clang" configuration file.
 //
-// NO-DEFAULT-CONFIG-NOT: Configuration file:
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1-GCC
 
-//--- Explicit --config works with --no-default-config.
+//--- "clang" + --driver-mode= should yield "*-clang++".
 //
-// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir=%S/Inputs/config --config-user-dir= --no-default-config --config i386-qqq.cfg -c -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-EXPLICIT-NO-DEFAULT
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang --driver-mode=g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1
+
+//--- Clang started via name prefix that is not valid is forcing that prefix instead of target triple.
+//
+// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix QQQ
+//
+// QQQ-NOT: Configuration file:
+// QQQ: Configuration file: {{.*}}/testdmode/qqq-clang-g++.cfg
+// QQQ-NOT: Configuration file:
+
+//--- Explicit --target= overrides the triple even with non-standard name prefix.
 //
-// CHECK-EXPLICIT-NO-DEFAULT-NOT: Configuration file: {{.*}}/testdmode/qqq-clang-g++.cfg
-// CHECK-EXPLICIT-NO-DEFAULT: Configuration file: {{.*}}/Inputs/config/i386-qqq.cfg
+// RUN: %t/testdmode/qqq-clang-g++ --target=x86_64-unknown-linux-gnu --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL1
 
-//--- Invocation qqq-clang-g++ tries to find config file qqq.cfg if qqq-clang-g++.cfg is not found.
+//--- "x86_64" prefix does not form a valid triple either.
 //
+// RUN: %t/testdmode/x86_64-clang --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix X86_64
+//
+// X86_64-NOT: Configuration file:
+// X86_64: Configuration file: {{.*}}/testdmode/x86_64-clang.cfg
+// X86_64-NOT: Configuration file:
+
+//--- Try cheribsd prefix using misordered triple components.
+//
+// RUN: %t/testdmode/cheribsd-riscv64-hybrid-clang++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix CHERIBSD
+//
+// CHERIBSD-NOT: Configuration file:
+// CHERIBSD: Configuration file: {{.*}}/testdmode/cheribsd-riscv64-hybrid-clang++.cfg
+// CHERIBSD-NOT: Configuration file:
+
+//--- Test fallback to x86_64-unknown-linux-gnu-clang-g++.cfg.
+//
+// RUN: rm %t/testdmode/x86_64-unknown-linux-gnu-clang++.cfg
+// RUN: rm %t/testdmode/i386-unknown-linux-gnu-clang++.cfg
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL2
+//
+// FULL2-NOT: Configuration file:
+// FULL2: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu-clang-g++.cfg
+// FULL2-NOT: Configuration file:
+
+//--- FULL2 + -m32.
+//
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ -m32 --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL2-I386
+//
+// FULL2-I386-NOT: Configuration file:
+// FULL2-I386: Configuration file: {{.*}}/testdmode/i386-unknown-linux-gnu-clang-g++.cfg
+// FULL2-I386-NOT: Configuration file:
+
+//--- Test fallback to x86_64-unknown-linux-gnu-clang.cfg + clang++.cfg.
+//
+// RUN: rm %t/testdmode/cheribsd-riscv64-hybrid-clang++.cfg
 // RUN: rm %t/testdmode/qqq-clang-g++.cfg
-// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir= --config-user-dir= -c -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix SHORT-NAME
+// RUN: rm %t/testdmode/x86_64-clang.cfg
+// RUN: rm %t/testdmode/x86_64-unknown-linux-gnu-clang-g++.cfg
+// RUN: rm %t/testdmode/i386-unknown-linux-gnu-clang-g++.cfg
+// RUN: rm %t/testdmode/x86_64-unknown-linux-gnu-clang.cfg
+// RUN: rm %t/testdmode/i386-unknown-linux-gnu-clang.cfg
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL3
 //
-// SHORT-NAME: Configuration file: {{.*}}/testdmode/qqq.cfg
-// SHORT-NAME: -Werror
-// SHORT-NAME-NOT: -Wundefined-func-template
+// FULL3-NOT: Configuration file:
+// FULL3: Configuration file: {{.*}}/testdmode/clang++.cfg
+// FULL3-NOT: Configuration file:
+// FULL3: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu.cfg
+// FULL3-NOT: Configuration file:
 
+//--- FULL3 + -m32.
+//
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ -m32 --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL3-I386
+//
+// FULL3-I386-NOT: Configuration file:
+// FULL3-I386: Configuration file: {{.*}}/testdmode/clang++.cfg
+// FULL3-I386-NOT: Configuration file:
+// FULL3-I386: Configuration file: {{.*}}/testdmode/i386-unknown-linux-gnu.cfg
+// FULL3-I386-NOT: Configuration file:
 
-//--- Config files are searched for in binary directory as well.
+//--- FULL3 + --driver-mode=.
 //
-// RUN: mkdir %t/testbin
-// RUN: ln -s %clang %t/testbin/clang
-// RUN: echo "-Werror" > %t/testbin/aaa.cfg
-// RUN: %t/testbin/clang --config-system-dir= --config-user-dir= --config aaa.cfg -c -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-BIN
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --driver-mode=gcc --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL3-GCC
 //
-// CHECK-BIN: Configuration file: {{.*}}/testbin/aaa.cfg
-// CHECK-BIN: -Werror
+// FULL3-GCC-NOT: Configuration file:
+// FULL3-GCC: Configuration file: {{.*}}/testdmode/clang.cfg
+// FULL3-GCC-NOT: Configuration file:
+// FULL3-GCC: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu.cfg
+// FULL3-GCC-NOT: Configuration file:
 
+//--- QQQ fallback.
+//
+// RUN: %t/testdmode/qqq-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix QQQ-FALLBACK
+//
+// QQQ-FALLBACK-NOT: Configuration file:
+// QQQ-FALLBACK: Configuration file: {{.*}}/testdmode/clang++.cfg
+// QQQ-FALLBACK-NOT: Configuration file:
+// QQQ-FALLBACK: Configuration file: {{.*}}/testdmode/qqq.cfg
+// QQQ-FALLBACK-NOT: Configuration file:
 
-//--- If command line contains options that change triple (for instance, -m32), clang tries
-//    reloading config file.
+//--- "x86_64" falback.
+//
+// RUN: %t/testdmode/x86_64-clang --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix X86_64-FALLBACK
+//
+// X86_64-FALLBACK-NOT: Configuration file:
+// X86_64-FALLBACK: Configuration file: {{.*}}/testdmode/clang.cfg
+// X86_64-FALLBACK-NOT: Configuration file:
+// X86_64-FALLBACK: Configuration file: {{.*}}/testdmode/x86_64.cfg
+// X86_64-FALLBACK-NOT: Configuration file:
 
-//--- When reloading config file, x86_64-clang-g++ tries to find config i386-clang-g++.cfg first.
+//--- cheribsd fallback.
 //
-// RUN: mkdir %t/testreload
-// RUN: ln -s %clang %t/testreload/x86_64-clang-g++
-// RUN: echo "-Wundefined-func-template" > %t/testreload/i386-clang-g++.cfg
-// RUN: echo "-Werror" > %t/testreload/i386.cfg
-// RUN: echo "-Wall" > %t/testreload/x86_64-clang-g++.cfg
-// RUN: %t/testreload/x86_64-clang-g++ --config-system-dir= --config-user-dir= -c -m32 -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-RELOAD
+// RUN: %t/testdmode/cheribsd-riscv64-hybrid-clang++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix CHERIBSD-FALLBACK
 //
-// CHECK-RELOAD: Configuration file: {{.*}}/testreload/i386-clang-g++.cfg
-// CHECK-RELOAD: -Wundefined-func-template
-// CHECK-RELOAD-NOT: -Werror
-// CHECK-RELOAD-NOT: -Wall
+// CHERIBSD-FALLBACK-NOT: Configuration file:
+// CHERIBSD-FALLBACK: Configuration file: {{.*}}/testdmode/clang++.cfg
+// CHERIBSD-FALLBACK-NOT: Configuration file:
+// CHERIBSD-FALLBACK: Configuration file: {{.*}}/testdmode/cheribsd-riscv64-hybrid.cfg
+// CHERIBSD-FALLBACK-NOT: Configuration file:
 
-//--- Same for -target in place of -m32.
-// RUN: %t/testreload/x86_64-clang-g++ --config-system-dir= --config-user-dir= -c -target i386 -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-RELOAD
+//--- Test fallback to x86_64-unknown-linux-gnu.cfg + clang-g++.cfg.
+//
+// RUN: rm %t/testdmode/clang++.cfg
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL4
+//
+// FULL4-NOT: Configuration file:
+// FULL4: Configuration file: {{.*}}/testdmode/clang-g++.cfg
+// FULL4-NOT: Configuration file:
+// FULL4: Configuration file: {{.*}}/testdmode/x86_64-unknown-linux-gnu.cfg
+// FULL4-NOT: Configuration file:
 
-//--- `-target i386 -m64` should load the 64-bit config.
-// RUN: %t/testreload/x86_64-clang-g++ --config-system-dir= --config-user-dir= -c -target i386 -m64 -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-RELOAD1a
+//--- Test fallback to clang-g++.cfg if x86_64-unknown-linux-gnu-clang.cfg does not exist.
+//
+// RUN: rm %t/testdmode/x86_64-unknown-linux-gnu.cfg
+// RUN: rm %t/testdmode/i386-unknown-linux-gnu.cfg
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL5
 //
-// CHECK-RELOAD1a: Configuration file: {{.*}}/testreload/x86_64-clang-g++.cfg
-// CHECK-RELOAD1a: -Wall
-// CHECK-RELOAD1a-NOT: -Werror
-// CHECK-RELOAD1a-NOT: -Wundefined-func-template
+// FULL5-NOT: Configuration file:
+// FULL5: Configuration file: {{.*}}/testdmode/clang-g++.cfg
+// FULL5-NOT: Configuration file:
 
-//--- x86_64-clang-g++ tries to find config i386.cfg if i386-clang-g++.cfg is not found.
+//--- FULL5 + -m32.
 //
-// RUN: rm %t/testreload/i386-clang-g++.cfg
-// RUN: %t/testreload/x86_64-clang-g++ --config-system-dir= --config-user-dir= -c -m32 -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-RELOAD1d
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ -m32 --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix FULL5-I386
 //
-// CHECK-RELOAD1d: Configuration file: {{.*}}/testreload/i386.cfg
-// CHECK-RELOAD1d: -Werror
-// CHECK-RELOAD1d-NOT: -Wundefined-func-template
-// CHECK-RELOAD1d-NOT: -Wall
+// FULL5-I386-NOT: Configuration file:
+// FULL5-I386: Configuration file: {{.*}}/testdmode/clang-g++.cfg
+// FULL5-I386-NOT: Configuration file:
 
-//--- x86_64-clang-g++ uses x86_64-clang-g++.cfg if i386*.cfg are not found.
+//--- Test that incorrect driver mode config file is not used.
 //
-// RUN: rm %t/testreload/i386.cfg
-// RUN: %t/testreload/x86_64-clang-g++ --config-system-dir= --config-user-dir= -c -m32 -no-canonical-prefixes -### %s 2>&1 | FileCheck %s -check-prefix CHECK-RELOAD1a
+// RUN: rm %t/testdmode/clang-g++.cfg
+// RUN: %t/testdmode/x86_64-unknown-linux-gnu-clang-g++ --config-system-dir= --config-user-dir= -no-canonical-prefixes --version 2>&1 | FileCheck %s -check-prefix NO-CONFIG