Adds a new build option for clang, CLANG_INCLUDE_EXAMPLES, which
controls if the examples directory is included in the build. It defaults
to the value for LLVM_INCLUDE_EXAMPLES (same as CLANG_INCLUDE_DOCS and
CLANG_INCLUDE_TESTS)
Signed-off-by: Jade Abraham <jademabraham17@gmail.com>
This is an attempt to replicate similar fearture already available to
clang. The changes in this patch were made with an intent to reuse as
much of existing infrastructure as possible. Namely, two-stage build
arrangement, perf-helper.py script and the means for building of the
instrumented binaries have all been incorporated into this approach.
It was deliberately chosen to optimize clang along with flang as they
are mostly working together in the final toolchain.
See the `llvm/docs/AdvancedBuilds.rst` documentation for more details.
Note that the attempt to optimize flang has exceeded one of the BOLT
limitations. The size of one of the statically allocated buffers needed
to be extended in this patch.
This allows specifying a fixed host linker version during Clang
configuration (e.g. -DHOST_LINK_VERSION=1249), bypassing the default
auto-detection. This is useful for hermetic packaging scripts where the
auto-detected host linker might differ from the intended target linker,
and we do not want certain features to be enabled that depends on the
host linker version -- e.g.
https://github.com/llvm/llvm-project/issues/203385
perf-training defines the generate-profdata target used by the PGO
bootstrap build.
However, it is currently enabled only when CLANG_INCLUDE_TESTS=ON.
For distribution builds such as Yocto/OE, tests are usually disabled by
setting this to OFF.
But perf-training is a PGO utility, not a test target, and it is
currently gated by that block.
As a result, generate-profdata is unavailable to the PGO bootstrap build
when
CLANG_INCLUDE_TESTS=OFF.
Move perf-training out of the CLANG_INCLUDE_TESTS block.
This is safe because utils/perf-training/CMakeLists.txt adds targets
only when
LLVM_BUILD_INSTRUMENTED or CLANG_BOLT is enabled, so moving it out does
not add
any targets unless PGO or BOLT is actually in use.
Also fix the path in lit.site.cfg.in for standalone builds.
When llvm_src_dir is set from CMAKE_SOURCE_DIR, standalone clang builds
end up
using the clang source directory instead of the LLVM source directory.
Set it to the proper LLVM source location instead.
Assisted-by: claude
To enable the new constant interpreter by default at configure time.
I don't expect any distributions to set this for now but it's useful for
testing and I think we need it eventually.
This is a scaled down version of https://reviews.llvm.org/D136315.
The intent is largely the same as before[^1], but I've scaled down the
scope to try to avoid the issues that the previous patch caused:
- the changes are now opt-in based on enabling `CLANG_USE_XCSELECT`
- this only works when targeting macOS on a macOS host (this is the only
case supported by `libxcselect`[^2])
- calling `libxcselect` is done only when the target is `*-apple-macos*`
to avoid breaking many tests
Another reason to leave this as opt-in for now is that there are some
bugs in libxcselect that need fixing before it is safe to use by default
for all users. This has been reported to Apple as FB16081077.
[^1]: See also https://reviews.llvm.org/D109460 and #45225.
[^2]: https://developer.apple.com/documentation/xcselect?language=objc
We are seeing the build system uses the XCode's libtool when building
the 2nd stage of the clang on mac. We should use the llvm-libtool-darwin
from the previous stage clang build instead. This patch makes multi-stage
clang build to use llvm-libtool-darwin from the previous stage when targeting
mac.
Build on Clang-BOLT infrastructure to collect sample profile for CSSPGO.
Add CSSPGO.cmake and BOLT-CSSPGO.cmake to automate CSSPGO/+BOLT
Clang builds.
Note that `CLANG_PGO_TRAINING_DATA_SOURCE_DIR` is required as built-in
training set is inadequate for collecting sampled profile.
Hardware compatibility: CSSPGO requires synchronized (0-skid) call
and branch stacks, which is only available with Intel PEBS (Sandy
Bridge+),
AMD Zen3 with BRS, Zen4 with LBRv2+LBR_PMC_FREEZE, and Zen5 with LBRv2.
This patch adds support for Intel `br_inst_retired.near_taken:uppp`
event.
Test Plan:
Added BOLT-CSSPGO.cmake with same use as BOLT-PGO.cmake,
e.g. for bootstrapped ThinLTO+CSSPGO+BOLT, with CSSPGO profile collected
from LLVM build, and BOLT profile collected from Hello World
(instrumentation):
```
cmake -B clang-csspgo-bolt -S /path/to/llvm-project/llvm \
-DLLVM_ENABLE_LLD=ON -DBOOTSTRAP_LLVM_ENABLE_LLD=ON \
-DBOOTSTRAP_BOOTSTRAP_LLVM_ENABLE_LLD=ON \
-DPGO_INSTRUMENT_LTO=Thin \
-DBOOTSTRAP_CLANG_PGO_TRAINING_DATA_SOURCE_DIR=/path/to/llvm-project/llvm \
-GNinja -C /path/to/llvm-project/clang/cmake/caches/BOLT-CSSPGO.cmake
ninja stage2-clang-bolt
...
warning: Sample PGO is estimated to optimize better with 19.5x more samples. Please consider increasing sampling rate or profiling for longer duration to get more samples.
...
[2800/2801] Optimizing Clang with BOLT
BOLT-INFO: 8189 out of 106942 functions in the binary (7.7%) have non-empty execution profile
13776393 : taken branches (-42.1%)
```
Performance testing with Clang:
- Setup: Clang-BOLT testing harness
9f2b46f67a
- CSSPGO training: building LLVM,
- InstrPGO training: building Hello World,
- BOLT training: building Hello World, instrumentation,
- benchmark: building small LLVM tool (not),
- 2S Intel SKX Xeon 6138 with 40C/80T and 256GB RAM, using 20C/40T for
build,
- Results, wall time, lower is better
- Baseline (bootstrapped build): 10.36s,
- InstrPGO + ThinLTO: 9.34s,
- CSSPGO + ThinLTO: 8.85s.
- BOLT results, for reference:
- Baseline: 9.09s,
- InstrPGO + ThinLTO: 9.09s,
- CSSPGO + ThinLTO: 8.58s.
---------
Co-authored-by: Matthias Braun <matze@braunis.de>
When cross-compiling the LLVM project as a whole (from llvm/), if it
cannot find presupplied tools it will create a native build environment
to build the tools it needs.
However, when doing a standalone build of clang (that is, from clang/
and linking against an existing libLLVM) this doesn't work. Instead a
_target_ binary is built which predictably then fails.
The conventional workaround for this is to build the native tools in a
separate native compile phase and pass the paths to the cross build, for
example see OpenEmbedded[1] or Nix[2]. But we can do better!
The first problem is that LLVM_USE_HOST_TOOLS is only set in the llvm/
CMakeLists.txt, so setup_host_tool() will never consider building a
native binary. This can be solved by setting LLVM_USE_HOST_TOOLS based
on CMAKE_CROSSCOMPILING in clang/CMakeLists.txt in the standalone case.
Now setup_host_tool() will try to build a native tool, but it needs
build_native_tool() from CrossCompile.cmake, so that also needs to be
included.
Finally, the native binary then fails because there's no provider for
the dependency "CONFIGURE_Clang_NATIVE", so use llvm_create_cross_target
to create the native environment.
These few lines mirror what the lldb CMakeLists.txt does in the
standalone case, so there is prior art for this.
[1]
https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/clang/clang_git.bb?id=e18d697e92b55e57124e80234369d46575226386#n212
[2]
3354d448f2/pkgs/development/compilers/llvm/common/tblgen.nix (L54)
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- It `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-subperfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
Co-authored-by: Rainer Orth <ro@gcc.gnu.org>
Fix running tests that require Z3 headers in standalone build. They were
wrongly relying on `Z3_INCLUDE_DIR` being passed through from LLVM,
which is not the case for a standalone build. Instead, perform
`find_package(Z3)` again to find Z3 development files and set
`Z3_INCLUDE_DIR`. While at it, handle the possibility that Z3
development package is no longer installed -- run the tests only if both
LLVM has been built against Z3, and the headers are still available.
https://github.com/llvm/llvm-project/pull/145731#issuecomment-3009487525
Signed-off-by: Michał Górny <mgorny@gentoo.org>
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- If `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-superfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate.
- AArch64 doesn't `FAIL` any longer, so no `XFAIL` is necessary.
- It keeps the `check-clang-python` target for use by the Clang Python
CI.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
As discussed in PR #142353, the current testsuite of the `clang` Python
bindings has several issues:
- If `libclang.so` cannot be loaded into `python` to run the testsuite,
the whole `ninja check-all` aborts.
- The result of running the testsuite isn't report like the `lit`-based
tests, rendering them almost invisible.
- The testsuite is disabled in a non-obvious way (`RUN_PYTHON_TESTS`) in
`tests/CMakeLists.txt`, which again doesn't show up in the test results.
All these issues can be avoided by integrating the Python bindings tests
with `lit`, which is what this patch does:
- The actual test lives in `clang/test/bindings/python/bindings.sh` and
is run by `lit`.
- The current `clang/bindings/python/tests` directory (minus the
now-superfluous `CMakeLists.txt`) is moved into the same directory.
- The check if `libclang` is loadable (originally from PR #142353) is
now handled via a new `lit` feature, `libclang-loadable`.
- The various ways to disable the tests have been turned into `XFAIL`s
as appropriate. This isn't complete and not completely tested yet.
- It keeps the `check-clang-python` target for use by the Clang Python
CI.
Tested on `sparc-sun-solaris2.11`, `sparcv9-sun-solaris2.11`,
`i386-pc-solaris2.11`, `amd64-pc-solaris2.11`, `i686-pc-linux-gnu`, and
`x86_64-pc-linux-gnu`.
This was added a long time ago..
* to the Makefiles in 40fee6313df688d43d1f8bbe85bc35161689afca;
* first to CMake in b3ce035c7155644d5bced46c45ae5ac865b7aedc;
* then moved to only apply when building Clang with GCC in
c5635a6af7.
This shouldn't be needed these days. If an issue does arise, it really
ought to be documented better and the cause will certainly be different
than it was back then.
The two GCC bugs cited in 40fee6313d were:
* https://gcc.gnu.org/PR41874
* https://gcc.gnu.org/PR41838
and both are long-fixed. Not only that, if those issues did come up again,
we'd be better off doing -Wno-strict-aliasing where appropriate if there
weren't a real code issue or some suppression that was tighter in scope
wasn't appropriate.
In #138329, _GNU_SOURCE was added for Cygwin, but when building Clang
standalone against an installed LLVM this definition was not picked up,
resulting in undefined strnlen. Follow the documentation in
https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project and add
the LLVM_DEFINITIONS in standalone projects' cmakes.
In the discussion around #116792, @rjmccall mentioned that ARCMigrate
has been obsoleted and that we could go ahead and remove it from Clang,
so this patch does just that.
Use LLVM_VERSION_MAJOR instead as the maximum allowed value. This change
is needed to fix regression tests that fail when vendors set
CLANG_VERSION_MAJOR to a value that is lower than LLVM_VERSION_MAJOR
when building the compiler.
For example, clang/test/CodeGenCXX/mangle-concept.cpp fails with the
following error if -DCLANG_VERSION_MAJOR=17 is passed to cmake:
invalid value '19' in '-fclang-abi-compat=19'
This change removes the need to call the clang-bolt target in order to
apply bolt optimizations to clang. Now running `ninja clang` will build
a clang with bolt optimizations, and `ninja check-clang` and `ninja
install-clang` will test and install bolt optimized clang too.
The clang-bolt target has been kept for compatibilty reasons, but it is
now just an alias to the clang target.
Also, this new design for applying the bolt optimizations to clang will
be easier to generalize and use to optimize other binaries/libraries in
the project.
---------
Co-authored-by: Amir Ayupov <fads93@gmail.com>
Co-authored-by: Petr Hosek <phosek@google.com>
In Clang-BOLT step, preserve pre-BOLT Clang binary (as well as clang++
symlink).
Also modify the default set of BOLT flags:
- drop ICF (can mess with unwinders),
- switch from hfsort+ to cdsort (aliases),
- enable CDSplit,
- update debug sections.
Reviewers: maksfb
Reviewed By: maksfb
Pull Request: https://github.com/llvm/llvm-project/pull/109351
GCC usually doesn't warn about unrecognized -Wno-<foo> options, if no
diagnostics are printed. However if some diagnostics are printed, it
also mentions that there were unrecognized -Wno-<foo> options.
Before 4feae05c6a, we checked for whether
-Wnested-anon-types was supported, and added the -Wno-<foo> form if the
positive form of the option was supported.
As of GCC 14, -Wnested-anon-types isn't supported, thus limit the use of
the option to actual Clang (and still only while using the GCC
compatible driver).
This avoids unnecessary mentions about unrecognized -Wno-<foo> options
when building with GCC.
This fixes two problems with the 2-stage PGO builds. The first problem
was that the stage2-instrumented and stage2 targets would not be built
on the second ninja invocation. For example:
This would work as expected.
$ ninja -v -C build stage2-instrumented-generate-profdata
Edit a file.
$ touch llvm/lib/Support/StringExtras.cpp
This would rebuild stage1 only and not build stage2-instrumented or
regenerate the profile data.
$ ninja -v -C build stage2-instrumented-generate-profdata
The second problem was that in some cases, the profile data would be
regenerated, but not all of the stage2 targets would be rebuilt. One
common scenario where this would happen is:
This would work as expected.
$ ninja -C build stage2-check-all
This would regenerate the profile data, but then only build the
targets that were needed for install, but weren't needed for
check-all. This would cause errors like:
ld.lld: error: Function Import: link error: linking module flags
'ProfileSummary': IDs have conflicting values in ...
This is because the executibles being built for the install target
used the new profile data, but they were linking with libraries that
used the old profile data.
$ ninja -C build stage2-install
With this change we can re-enable PGO for the release builds.
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode (`set_property(TARGET <target>
PROPERTY FOLDER "<title>")`) when using the respective CMake's IDE
generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
This patch remove 36 checks for compiler flags that are done via
invoking the compiler across LLVM, Clang, and LLDB. It's was made
possible by raising the bar for supported compilers that has been
happening over the years since the checks were added.
This is going to improve CMake configuration times. This topic was
highlighted in
https://discourse.llvm.org/t/cmake-compiler-flag-checks-are-really-slow-ideas-to-speed-them-up/78882.
`clang/tools/scan-build` is implemented in `perl`. However given `perl`
is not mentioned as a required dependency in `GettingStarted.rst` we
should make this optional.
This adds a `find_package(Perl)` check to cmake and disables the
`scan-build` tests when no perl executable is found.
Ideally we would also check if dependent perl modules like `Hash::Util`
are present on the system, but I don't see any pre-existing cmake macros
to easily test this. So for now I go with a plain check for the `perl`
package, at least this allows to use `cmake
-DCMAKE_DISABLE_FIND_PACKAGE_Perl=ON` to manually disable `perl` and the
tests.
This adds no real content, it just incrementally adds some scaffolding
necessary to enable a future patch to just add our first few ops.
Test Plan:
```
$ cmake -Sllvm -Bbuild -DCLANG_ENABLE_CIR=1 \
-DLLVM_ENABLE_PROJECTS='clang;mlir' \
-DCMAKE_BUILD_TYPE=Release -GNinja
$ ninja -C build check-clang
$ ninja -C build MLIRCIROpsIncGen
$ ninja -C build MLIRCIR
```
Reviewers: AaronBallman, erichkeane, bcardosolopes
Reviewed By: erichkeane, AaronBallman, bcardosolopes
Pull Request: https://github.com/llvm/llvm-project/pull/86080
Introduce a cmake variable that guards the inclusion of ClangIR into the
build of clang. Guard that we aren't trying to build without MLIR. Add
two subdirectories that, as of now, don't do anything.
Reviewers: bcardosolopes, erichkeane, petrhosek, Ericson2314
Reviewed By: bcardosolopes
Pull Request: https://github.com/llvm/llvm-project/pull/86078
Move the code adding top-level cmake/Modules directory to
CMAKE_MODULE_PATH prior to including `GetDarwinLinkerVersion`, in order
to fix standalone builds.
Fixes a regression introduced by
3bc71c2abf.
The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the tests. This allows a clang built on a machine with a new linker
to run compiler-rt tests on a machine with an old linker.
rdar://125198603
unless USE_DEPRECATED_GCC_INSTALL_PREFIX (temporary escape hatch) is
set. Setting GCC_INSTALL_PREFIX leads to a warning for Clang 18.1
(#77537) and will be completely removed for Clang 20.
Link:
discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091
Link:
discourse.llvm.org/t/correct-cmake-parameters-for-building-clang-and-lld-for-riscv/72833
Split up and refactor CLANG_BOLT_INSTRUMENT into support for
BOLT instrumentation, perf no-LBR and perf with LBR profiling.
Differential Revision: https://reviews.llvm.org/D143617
Part of https://reviews.llvm.org/D158218
GCC_INSTALL_PREFIX is a rarely-used legacy option inherited from
pre-CMake build system and has configuration file replacement nowadays.
Many `clang/test/Driver` tests specify `--gcc-toolchain=` to prevent
failures when `GCC_INSTALL_PREFIX` is specified: some contributors add
them to fix tests and some just do cargo culting. This is not healthy
for contributors adding cross compilation support for this rarely used
option.
`DEFAULT_SYSROOT` should in spirit be deprecated as well, but a relative
path doesn't have good replacement, so don't deprecate it for now.
Link:
https://discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091
Link:
https://discourse.llvm.org/t/correct-cmake-parameters-for-building-clang-and-lld-for-riscv/72833
---
With `GCC_INSTALL_PREFIX=/usr`, `clang a.c` behaves like
`clang --gcc-toolchain=/usr a.c`.
Here is a simplified version of GCC installation detection code.
```
if (OPT_gcc_install_dir_EQ)
return OPT_gcc_install_dir_EQ;
if (OPT_gcc_triple)
candidate_gcc_triples = {OPT_gcc_triple};
else
candidate_gcc_triples = collectCandidateTriples();
if (OPT_gcc_toolchain)
prefixes = {OPT_gcc_toolchain};
else
prefixes = {OPT_sysroot/usr, OPT_sysroot};
for (prefix : prefixes)
if "$prefix/lib/gcc" exists // also tries $prefix/lib/gcc-cross
for (triple : candidate_gcc_triples)
if "$prefix/lib/gcc/$triple" exists
return "$prefix/lib/gcc/$triple/$version"; // pick the largest version
```
`--gcc-toolchain=` specifies a directory where
`lib/gcc{,-cross}/$triple/$version` can be found. If you actually want
to use a specific version of GCC, specify something like
`--gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11` in a configuration
file. You can also specify `--gcc-triple=`.
On Debian and its derivatives where the target triple omits the vendor
part, the following ways are roughly equivalent, except that
`--gcc-install-dir=` specifies a version as well:
```
clang --gcc-toolchain=/usr a.c
clang --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 a.c
clang --gcc-triple=x86_64-linux-gnu a.c
```
The modules build trips over this frequently because there is no textual
include of the tablegen output, but the module includes it.
Differential revision: https://reviews.llvm.org/D157119
