Fat lto with -c compiles to an object file with the IR embedded in a
section of the object, the combination of fat-lto with -S should then
produce an assembly file equivalent of that. The IR output can still be
genreated by using both -S and -emit-llvm.
This implements a way for the compiler to find the modules.json
associated with the C++23 Standard library modules.
This is based on a discussion in SG15. At the moment no Standard library
installs this manifest. #75741 adds this feature in libc++.
Add the -fspv-target-env option to the clang-dxc compatibility driver to
specify the SPIR-V target environment, which is propagated to the target
Triple.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch renames {starts,ends}with to {starts,ends}_with for
consistency with std::{string,string_view}::{starts,ends}_with in
C++20. Since there are only a handful of occurrences, this patch
skips the deprecation phase and simply renames them.
Add an option to target SPIR-V to the clang-dxc driver, which sets the
target triple's architecture to logical SPIR-V. This does not yet
address the need for a Vulkan target environment in the triple, tracked
in Issue #70051.
Depends on #70330
clang-cl is a driver mode that accepts options of MSVC cl.exe as a
drop-in replacement for cl.exe. Currently clang-cl accepts mixed clang
style options and cl style options. To let clang-cl accept a clang-style
option, just need to add visibility CLOption to that option.
Currently nvcc can pass cl style options to cl.exe, which allows nvcc to
compile C++ and CUDA programs with mixed nvcc and cl style options. On
the other hand, clang cannot use mixed clang and cl style options to
compile CUDA/HIP programs.
This patch add visibility CLOption to options needed to compile CUDA/HIP
programs. This allows clang-cl to compile CUDA/HIP programs with mixed
clang and cl style options.
This patch adds the Driver changes needed for enabling HIP parallel algorithm offload on AMDGPU targets. What this change does can be summed up as follows:
- add two flags, one for enabling `hipstdpar` compilation, the second enabling the optional allocation interposition mode;
- the flags correspond to new LangOpt members;
- if we are compiling or linking with --hipstdpar, we enable HIP; in the compilation case C and C++ inputs are treated as HIP inputs;
- the ROCm / AMDGPU driver is augmented to look for and include an implementation detail forwarding header; we error out if the user requested `hipstdpar` but the header or its dependencies cannot be found.
Tests for the behaviour described above are also added.
Reviewed by: MaskRay, yaxunl
Differential Revision: https://reviews.llvm.org/D155775
```
$ ./bin/clang --target=arm-linux-gnueabihf --print-supported-extensions
<...>
All available -march extensions for ARM
crc
crypto
sha2
aes
dotprod
<...>
```
This follows the format set by RISC-V and AArch64. As for AArch64, ARM
doesn't have versioned extensions like RISC-V does. So there is only 1
column, which contains the name.
Any extension without a "feature" is hidden as these cannot be used with
-march.
The upstream commit: https://reviews.llvm.org/D151590
added a new flag to mark target specific compiler options.
The side effect of it was that in cases when -### or -v is used without any
input file, clang started emitting an error.
It happened like that becasue there is no compilation actions created
which could consume/verify these target specific options.
This patch changes that error to a warning about unused option in situations
when there is no actions and still generates error when there are actions.
Fix for https://github.com/llvm/llvm-project/issues/64958
Differential Revision: https://reviews.llvm.org/D159361
This follows the RISC-V work done in
4b40ced4e5.
This uses AArch64's target parser instead. We just list the names,
without the "+" on them, which matches RISC-V's format.
```
$ ./bin/clang -target aarch64-linux-gnu --print-supported-extensions
clang version 18.0.0 (https://github.com/llvm/llvm-project.git 154da8aec20719c82235a6957aa6e461f5a5e030)
Target: aarch64-unknown-linux-gnu
Thread model: posix
InstalledDir: <...>
All available -march extensions for AArch64
aes
b16b16
bf16
brbe
crc
crypto
cssc
<...>
```
Since our extensions don't have versions in the same way there's just
one column with the name in.
Any extension without a feature name (including the special "none") is
not listed as those cannot be passed to -march, they're just for the
backend. For example the MTE extension can be added with "+memtag" but
MTE2 and MTE3 do not have feature names so they cannot be added to
-march.
This does not attempt to tackle the fact that clang allows invalid
combinations of AArch64 extensions, it simply lists the possible
options. It's still up to the user to ask for something sensible.
Equally, this has no context of what CPU is being selected. Neither does
the RISC-V option, the user has to be aware of that.
I've added a target parser test, and a high level clang test that checks
RISC-V and AArch64 work and that Intel, that doesn't support this, shows
the correct error.
This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```
It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```
I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.
Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.
Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.
Modify my AIX cleanup cd18efb61d to
add an err_drv_unsupported_opt_for_target.
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D159173
This revision supports --print-supported-extensions,
it prints out all of the extensions and corresponding version supported.
Reviewed By: craig.topper, kito-cheng
Differential Revision: https://reviews.llvm.org/D146054
After this D108637 and with FreeBSD -current and now 14 dropping support for
CloudABI I think it is time to consider deleting the CloudABI support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158920
This used to be getRuntimePath till https://reviews.llvm.org/D115049
added a fallback search path for Android. As far as I can tell, the
intent has always been to use the first existing path though instead of
actually supporting multiple runtime paths. We can move the existence
checks into getRuntimePath and have it return std::optional, which also
makes the `--print-runtime-dir` behavior much cleaner.
The motivation is a follow-up change to Android runtime path searches,
which is much nicer with this in place.
Reviewed By: phosek, MaskRay
Differential Revision: https://reviews.llvm.org/D158475
After looking at this further I think the Ananas support should be removed.
They stopped using Clang. There have never been any releases either; as in
source only, and the backend is not maintained.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158946
I am trying to clean up GCCInstallationDetector::init and noticed that
Myriad.cpp is the only toolchain using `ExtraTripleAliases`. This is a
little overhead, but I figured that Myriad.cpp is unused.
Its sanitizer runtime part was removed in 2021 by D104279. It seems time
to retire it.
Reviewed By: waltl
Differential Revision: https://reviews.llvm.org/D158706
Minix is a ToolChain that was added back in 2010 but has been
unmaintained with no test. The constructed command line contains
/usr/gnu/include/c++/4.4.3 and CompilerRT-Generic which are unlikely
working for a long time.
Contiki is a barebone ToolChain that just enables safestack.
This doesn't justify a new ToolChain.
Remove these ToolChains so that their target triples will use Generic_ELF instead.
If these developers feel like having an updated llvm-project is useful,
fixing other build issues and adding a new ToolChain is much better than
having the unmaintained ToolChains.
Reviewed By: brad
Differential Revision: https://reviews.llvm.org/D158461
warn_drv_overriding_flag_option was added for clang-cl `/T*` options (D1290) and its group name was planned to be renamed to overriding-option.
The name -Woverriding-t-option does not make sense for other uses,
mostly related to -ffp-model= related diagnostics.
Reviewed By: hans, skan, dexonsmith
Differential Revision: https://reviews.llvm.org/D158137
Prior to D157151, there was no mechanism to "disable" unsupported Clang
options in Flang. While the "help" text (`flang-new -help`) was indeed
configured not to display such options, the Flang compiler driver would
happily consume such options and only issue a warning when there was no
logic to parse it:
```
flang-new -fno-experimental-relative-c++-abi-vtables file.f90
flang-new: warning: argument unused during compilation: '-fno-experimental-relative-c++-abi-vtables'
```
D157151 introduces visibility flags. In particular, all Clang options
gain a visibility flag (`ClangOption`) that can be excluded when in
Flang driver mode. This way the above invocation will lead to:
```
flang-new: error: unknown argument '-fno-experimental-relative-c++-abi-vtables'; did you mean '-Xclang -fno-experimental-relative-c++-abi-vtables'?
```
This won't work unless all options/flags supported by Flang have their
visibility flags updated accordingly, hence the changes in Options.td.
Moving forward, this change will allow Flang better control over the
supported options.
Depends on D157151
Differential Revision: https://reviews.llvm.org/D157837
This splits the backend and assemble actions for HLSL inputs and
handles the options in GetNamedOutputPath instead of aliasing `-o`.
This also moves how we default to emitting asm to stdout, since doing
this in the HLSL toolchain rather than the driver pollutes how the
clang driver works as well.
When both options are specified we disable collapsing the assemble
action and attempt to generate both outputs. Note that while this
handles the driver aspects, we can't actually run in that mode for now
since -cc1as doesn't understand DXIL as an input yet.
Differential Revision: https://reviews.llvm.org/D157582
This is a big refactor of the clang driver's option handling to use
the Visibility flags introduced in https://reviews.llvm.org/D157149.
There are a few distinct parts, but they can't really be split into
separate commits and still be made to compile.
1. We split out some of the flags in ClangFlags to ClangVisibility.
Note that this does not include any subtractive flags.
2. We update the Flag definitions and OptIn/OptOut constructs in
Options.td by hand.
3. We introduce and use a script, update_options_td_flags, to ease
migration of flag definitions in Options.td, and we run that on
Options.td. I intend to remove this later, but I'm committing it so
that downstream forks can use the script to simplify merging.
4. We update calls to OptTable in the clang driver, cc1as, flang, and
clangd to use the visibility APIs instead of Include/Exclude flags.
5. We deprecate the Include/Exclude APIs and add a release note.
*if you are running into conflicts with this change:*
Note that https://reviews.llvm.org/D157150 may also be the culprit and
if so it should be handled first.
The script in `clang/utils/update_options_td_flags.py` can help. Take
the downstream side of all conflicts and then run the following:
```
% cd clang/include/clang/Driver
% ../../../utils/update_options_td_flags.py Options.td > Options.td.new
% mv Options.td.new Options.td
```
This will hopefully be sufficient, please take a look at the diff.
Differential Revision: https://reviews.llvm.org/D157151
Some Clang command-line handling code could benefit from the option's prefixed name being a `StringLiteral`. This patch changes the `llvm::opt` TableGen backend to generate and emit that into the .inc file.
Depends on D157028.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157029
We currently spell check options that are listed as unsupported, but
this doesn't make much sense. If an option is explicitly unsupported
why would one that's spelled similarly be useful?
It looks like the reason this was added was that we explicitly mark
all `--something` flags as Unsupported rather than just leaving them
undefined and treating them as unknown. Drop that handling so that we
don't regress on things like misspelling `--help`.
Differential Revision: https://reviews.llvm.org/D156925
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb1046: add -nogpulib to some AMDGPU tests
* 9155e517e6: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5b: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
* ab68df505e: add -resource-dir= and -fvisibility=hidden
to some -fsanitize=cfi tests
* d5ca1602f6: --rtlib=platform without --unwindlib= may fail if CLANG_DEFAULT_UNWINDLIB=unwindlib
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
An incomplete list of prerequisite test improvement:
* 2f79bb1046: add -nogpulib to some AMDGPU tests
* 9155e517e6: add --cuda-path= (test w/ and w/o /usr/local/cuda)
* 80765ede5b: -mcpu=native may return either 0 or 1, depending on whether `--target=` specifies a native target
* abae53f43f: fix -fuse-ld=lld misuses (test w/o and w/o /usr/local/bin/ld.lld)
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
This reverts commit e39bf32b3b.
Some tests have different behaviors depent on whether certain directories/files are present on the host.
An incomplete list from https://lab.llvm.org/buildbot/#/builders/109/builds/70149
csky-toolchain.c
riscv*-toolchain.c
fuchsia.*
hip-*
ohos.c
The exit code for -### is inconsistent. Unrecognized options lead to
exit code 1, as expected. However, most others errors (including invalid
option value) lead to exit code 0, differing from GCC and most utilities.
This is a longstanding quirk of -###, and we didn't fix it because many
driver tests need adjustment.
Change -### to be similar to -fdriver-only -v and exit with code 1.
This requires fixing many driver tests, but the end result gives us
stronger tests.
* Existing `RUN: %clang -### ...` tests usually don't use `CHECK-NOT: error:` or `--implicit-check-not=error:`.
If a change introduces an error, such a change usually cannot be detected.
* Many folks contributing new tests don't know `-fdriver-only -v`.
To test no driver error/warning for new tests, they can use the familiar `-### -Werror`
instead of `-fdriver-only -v -Werror`.
Reviewed By: jhuber6, yaxunl, dblaikie
Differential Revision: https://reviews.llvm.org/D156363
When we have both explicitly included and excluded option sets, we
were excluding anything from the latter set regardless of what was in
the former. This doesn't compose well and led to an overly complicated
design around DXC options where a third flag was introduced to handle
options that overlapped between DXC and CL.
With this change we check the included options before excluding
anything from the exclude list, which allows for options that are in
multiple categories to be handled in a sensible way. This allows us to
remove CLDXCOption but should otherwise be NFC.
Differential Revision: https://reviews.llvm.org/D155729
This warning primarily applies to users of the CUDA langues as there may
be new features we rely on. The other two users of the toolchain are
OpenMP via `-fopenmp --offload-arch=sm_70` and a cross-compiled build
via `--target=nvptx64-nvida-cuda -march=sm_70`. Both of these do not
rely directly on things that would change significantly between CUDA
versions, and the way they are built can sometims make this warning
print many times.
This patch changees the behaiour to only check for the version when
building for CUDA offloading specifically, the other two will not have
this check.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D155606
When compiling in device only mode (e.g. --offload-device-only), the
host linker phase would not happen and therefore, the driver should
ignore all the host linker flags.
Differential Revision: https://reviews.llvm.org/D154881
Change-Id: I8244acef5c33108cf15b1dbb188f974f30099718
Fat LTO objects contain both LTO compatible IR, as well as generated
object code. This allows users to defer the choice of whether to use LTO
or not to link-time. This is a feature available in GCC for some time,
and makes the existing -ffat-lto-objects flag functional in the same
way as GCC's.
This patch adds support for that flag in the driver, as well as setting the
necessary codegen options for the backend. Largely, this means we select
the newly added pass pipeline for generating fat objects.
Users are expected to pass -ffat-lto-objects to clang in addition to one
of the -flto variants. Without the -flto flag, -ffat-lto-objects has no
effect.
// Compile and link. Use the object code from the fat object w/o LTO.
clang -fno-lto -ffat-lto-objects -fuse-ld=lld foo.c
// Compile and link. Select full LTO at link time.
clang -flto -ffat-lto-objects -fuse-ld=lld foo.c
// Compile and link. Select ThinLTO at link time.
clang -flto=thin -ffat-lto-objects -fuse-ld=lld foo.c
// Compile and link. Use ThinLTO with the UnifiedLTO pipeline.
clang -flto=thin -ffat-lto-objects -funified-lto -fuse-ld=lld foo.c
// Compile and link. Use full LTO with the UnifiedLTO pipeline.
clang -flto -ffat-lto-objects -funified-lto -fuse-ld=lld foo.c
// Link separately, using ThinLTO.
clang -c -flto=thin -ffat-lto-objects foo.c
clang -flto=thin -fuse-ld=lld foo.o -ffat-lto-objects # pass --lto=thin --fat-lto-objects to ld.lld
// Link separately, using full LTO.
clang -c -flto -ffat-lto-objects foo.c
clang -flto -fuse-ld=lld foo.o # pass --lto=full --fat-lto-objects to ld.lld
Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977
Depends on D146776
Reviewed By: tejohnson, MaskRay
Differential Revision: https://reviews.llvm.org/D146777
We want lld-link to automatically find compiler-rt's and
libc++ when it's in the same directory as the rest of the
toolchain. This is because on Windows linking isn't done
via the clang driver - but instead invoked directly.
This prepends: <llvm>/lib <llvm>/lib/clang/XX/lib and
<llvm>/lib/clang/XX/lib/windows automatically to the library
search paths.
Related to #63827
Differential Revision: https://reviews.llvm.org/D151188
targeting MachO embedded architectures
Sometimes users pass this option when targeting embedded architectures
like armv7m on non-darwin platforms.
Emit a warning instead of erroring out, which restores the behavior
prior to 34d7acd444.
