clang/lib/Driver/ToolChains/Clang.cpp has a lot of fragments like the following:
```
if (const Arg *A = Args.getLastArg(...)) {
if (Triple is xxx)
A->render(Args, CmdArgs);
else
D.Diag(diag::err_drv_unsupported_opt_for_target) << ...;
}
```
The problem is more apparent with a recent surge of AIX-specific options.
Introduce the TargetSpecific flag so that we can move the target-specific
options to ToolChains/*.cpp and ToolChains/Arch/*.cpp and overload the
warn_drv_unused_argument mechanism to give an err_drv_unsupported_opt_for_target
error.
Migrate -march=/-mcpu= and some AIX-specific options to use this simplified pattern.
Reviewed By: jansvoboda11
Differential Revision: https://reviews.llvm.org/D151590
This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view.
Note that the llvm/ directory has migrated in commit
6c3ea866e9.
I'll post a separate patch to deprecate
StringRef::{starts,ends}with_insensitive.
Differential Revision: https://reviews.llvm.org/D150506
Inspired by D133662.
Close https://github.com/llvm/llvm-project/issues/57285
When -ftime-trace is specified and the driver performs both compilation and
linking phases, the trace files are currently placed in the temporary directory
(/tmp by default on *NIX). A more sensible behavior would be to derive the trace
file names from the -o option, similar to how GCC derives auxiliary and dump
file names. Use -dumpdir (D149193) to implement the -gsplit-dwarf like behavior.
The following script demonstrates the time trace filenames.
```
#!/bin/sh -e
PATH=/tmp/Rel/bin:$PATH # adapt according to your build directory
mkdir -p d e f
echo 'int main() {}' > d/a.c
echo > d/b.c
a() { rm $1 || exit 1; }
clang -ftime-trace d/a.c d/b.c # previously /tmp/[ab]-*.json
a a-a.json; a a-b.json
clang -ftime-trace d/a.c d/b.c -o e/x # previously /tmp/[ab]-*.json
a e/x-a.json; a e/x-b.json
clang -ftime-trace d/a.c d/b.c -o e/x -dumpdir f/
a f/a.json; a f/b.json
clang -ftime-trace=f d/a.c d/b.c -o e/x
a f/a-*.json; a f/b-*.json
clang -c -ftime-trace d/a.c d/b.c
a a.json b.json
clang -c -ftime-trace=f d/a.c d/b.c
a f/a.json f/b.json
clang -c -ftime-trace d/a.c -o e/xa.o
a e/xa.json
clang -c -ftime-trace d/a.c -o e/xa.o -dumpdir f/g
a f/ga.json
```
The driver checks `-ftime-trace` and `-ftime-trace=`, infers the trace file
name, and passes `-ftime-trace=` to cc1. The `-ftime-trace` cc1 option is
removed.
With offloading, previously `-ftime-trace` is passed to all offloading
actions, causing the same trace file to be overwritten by host and
offloading actions. This patch doesn't attempt to support offloading (D133662),
but makes a sensible change (`OffloadingPrefix.empty()`) to ensure we don't
overwrite the trace file.
Minor behavior differences: the trace file is now a result file, which
will be removed upon an error. -ftime-trace-granularity=0, like
-ftime-trace, can now cause a -Wunused-command-line-argument warning.
Reviewed By: Maetveis
Differential Revision: https://reviews.llvm.org/D150282
When the final phase is linking, Clang currently places `.dwo` files in the
current directory (like the `-c` behavior for multiple inputs).
Strangely, -fdebug-compilation-dir=/-ffile-compilation-dir= is considered, which
is untested.
GCC has a more useful behavior that derives auxiliary filenames from the final
output (-o).
```
gcc -c -g -gsplit-dwarf d/a.c d/b.c # a.dwo b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c -o e/x # e/x-a.dwo e/x-b.dwo
gcc -g -gsplit-dwarf d/a.c d/b.c # a-a.dwo a-b.dwo
```
Port a useful subset of GCC behaviors that are easy to describe to Clang.
* Add a driver and cc1 option -dumpdir
* When the final phase is link, add a default -dumpdir if not specified by the user
* Forward -dumpdir to -cc1 command lines
* tools::SplitDebugName prefers -dumpdir when constructing the .dwo filename
GCC provides -dumpbase. If we use just one of -dumpdir and -dumpbase,
-dumpbase isn't very useful as it appends a dash.
```
gcc -g -gsplit-dwarf -dumpdir e d/a.c # ea.dwo
gcc -g -gsplit-dwarf -dumpdir e/ d/a.c # e/a.dwo
gcc -g -gsplit-dwarf -dumpbase e d/a.c # e-a.dwo
gcc -g -gsplit-dwarf -dumpbase e/ d/a.c # e/-a.dwo
```
If we specify both `-dumpdir` and `-dumpbase`, we can avoid the influence of the
source filename when there is one input file.
```
gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c # f/x.dwo
gcc -g -gsplit-dwarf -dumpdir f/ -dumpbase x d/a.c d/b.c # f/x-a.dwo f/x-b.dwo
```
Given the above examples, I think -dumpbase is not useful.
GCC -save-temps has interesting interaction with -dumpdir as -save-temps
generated files are considered auxiliary files like .dwo files.
For Clang, with this patch, -save-temps and -dumpdir are orthogonal, which is
easier to explain.
```
gcc -g -gsplit-dwarf d/a.c -o e/x -dumpdir f/ -save-temps=obj # e/a.{i,s,o,dwo}
gcc -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # f/a.{i,s,o,dwo}
clang -g -gsplit-dwarf d/a.c -o e/x -save-temps=obj -dumpdir f/ # e/a.{i,s,o} f/a.dwo
```
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D149193
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Drive-by fixes c++1z -> c++17 and c++2a -> c++20 when seen.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D149553
Our downstream toolchain release got some issue is we set the default
triple by creating symbolic link of clang like `riscv64-unknown-elf-clang`,
and has lots of multi-lib config including rv32's config.
However when we trying to set arch by a 32 bit CPU like generic-rv32
but got error message below:
error: unsupported argument 'generic-rv32' to option '-mcpu='
`generic-rv32` is listed in the output of `-mcpu=help`, that
might be confusing for user since help message say supported.
So let clang driver also consider -mcpu option during computing
the target triple to archvie that.
Reviewed By: asb, craig.topper
Differential Revision: https://reviews.llvm.org/D148124
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
Using two environment variables `CC_PRINT_INTERNAL_STAT` and
`CC_PRINT_INTERNAL_STAT_FILE` to work like `CC_PRINT_PROC_STAT`.
The purpose of the change is to allow collecting the internal stats
without modifying the build scripts. Write all stats to a single file
to simplify aggregating the data.
Differential Revision: https://reviews.llvm.org/D144981
This change had tests that break whenever LLVM_ENABLE_LINKER_BUILD_ID is
set, as is the case in the Fuchsia target.
This reverts commits:
f81317a54572474afa27
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
Extract the code the driver uses to expand response files and reuse it
in the dependency scanner.
rdar://106155880
Differential Revision: https://reviews.llvm.org/D145838
GCC on AIX primarily uses the -maix32 and -maix64 to select the bitmode
to target. In order to be compatible with existing build configurations,
clang should accept these options as well. In this patch we implement
these options for AIX targets.
Differential Revision: https://reviews.llvm.org/D145610
Currently HIP toolchain uses Driver::GetTemporaryDirectory to
create a temporary directory for some temporary files during
compilation. The temporary directories are not automatically
deleted after compilation. This slows down compilation
on Windows.
Switch to use GetTemporaryPath which only creates temporay
files which will be deleted automatically.
Keep the original input file name convention for Darwin host
toolchain since it is needed for deterministic binary
(https://reviews.llvm.org/D111269)
Fixes: SWDEV-386058
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D145509
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
`/clang:-x` emits an error instead of a warning. And if the error is suppressed,
`/clang:-x` takes no effect.
Considering that `/clang:` is a recent addition in 2018-11 and there are MSVC
style alternatives, therefore `/clang:-x` doesn't seem useful and we just reject
it since properly supporting it would add lots of complexity.
Fixes#59307
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D142757
New option --dxv-path is added for dxc mode to set the installation path for dxv.
If cannot find dxv, a warning will be report.
dxv will be executed with command line dxv file_name -o file_name.
It will validate and sign the file and overwrite it.
Differential Revision: https://reviews.llvm.org/D141705
Currently, we embed device code into the host to perform
multi-architecture linking and handling of device code. If the user
specified `-S -emit-llvm` then the embedded output will be textual
LLVM-IR. This is a problem because it can't be used by the LTO backend
and it makes reading the file confusing.
This patch changes the behaviour to only emit textual device IR if we
are in device only mode, that is, if the device code is presented
directly to the user instead of being embedded. Otherwise we should
always embed device bitcode instead.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D141717
When used to find an exact match, some extra context can be used to
totally cut some computations.
This saves 1% of the instruction count when pre processing sqlite3.c
through
valgrind --tool=callgrind ./bin/clang -E sqlite3.c -o/dev/null
Differential Revision: https://reviews.llvm.org/D142026
Currently, the NVPTX compilation toolchain can only be invoked either
through CUDA or OpenMP via `--offload-device-only`. This is because we
cannot build a CUDA toolchain without an accompanying host toolchain for
the offloading. When using `--target=nvptx64-nvidia-cuda` this results
in generating calls to the GNU assembler and linker, leading to errors.
This patch abstracts the portions of the CUDA toolchain that are
independent of the host toolchain or offloading kind into a new base
class called `NVPTXToolChain`. We still need to read the host's triple
to build the CUDA installation, so if not present we just assume it will
match the host's system for now, or the user can provide the path
explicitly.
This should allow the compiler driver to create NVPTX device images
directly from C/C++ code.
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D140158
The patch implements `-fmodule-output=`. This is helpful if the build
systems want to generate these output files in other places which is not
the same with -o specified or the input file lived.
Reviewed By: dblaikie, iains
Differential Revision: https://reviews.llvm.org/D137059
Patches to support the one-phase compilation model for modules.
The behavior:
(1) If -o and -c is specified , the module file is in the same path
within the same directory as the output the -o specified and with a new
suffix .pcm.
(2) Otherwise, the module file is in the same path within the working
directory directory with the name of the input file with a new suffix
.pcm
For example,
```
Hello.cppm Use.cpp
```
A trivial one and the contents are ignored. When we run:
```
clang++ -std=c++20 -fmodule-output Hello.cppm -c
```
The directory would look like:
```
Hello.cppm Hello.o Hello.pcm Use.cpp
```
And if we run:
```
clang++ -std=c++20 -fmodule-output Hello.cppm -c -o output/Hello.o
```
Then the `output` directory may look like:
```
Hello.o Hello.pcm
```
Reviewed By: dblaikie, iains, tahonermann
Differential Revision: https://reviews.llvm.org/D137058
Currently, the behaviour of `-save-temps` changes the generated output
when offloading to AMDGPU. This is because we only have a single phase
and it contains the `-disable-llvm-passes` flags which results in
unoptimized bitcode. We need to make sure we generate another phase that
produces both the optimized and unoptimized bitcode. There used to be a
check that turned these phases into a no-op. But I believe it is more
correct to not generate them this way in the first place. Doing this
requires a bit of a hack, replacing an already generated phase action,
but it should be fine.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D141440
This patch adds support for '--offload-arch=native' to OpenMP
offloading. This will automatically generate the toolchains required to
fulfil whatever GPUs the user has installed. Getting this to work
requires a bit of a hack. The problem is that we need the ToolChain to
launch its searching program. But we do not yet have that ToolChain
built. I had to temporarily make the ToolChain and also add some logic
to ignore regular warnings & errors.
Depends on D141078
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D141105
This patch applies the same handling for the `--offload-arch=native'
string to the new driver. The support for OpenMP will require some extra
logic to infer the triples from the derived architecture strings.
Depends on D141051
Reviewed By: tra
Differential Revision: https://reviews.llvm.org/D141078
This patch adds basic support for `--offload-arch=native` to CUDA. This
is done using the `nvptx-arch` tool that was introduced previously. Some
of the logic for handling executing these tools was factored into a
common helper as well. This patch does not add support for OpenMP or the
"new" driver. That will be done later.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D141051
JIT support for OpenMP offloading was introduced in D139287. This patch
adds a simple flag that enables this mode. It simply requires enabling
`-foffload-lto` mode and `--embed-bitcode` in the linker wrapper. This
option implies LTO if it is not enabled.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D141158
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This fixes clang.
This patch detects system GPU and use them
in --offload-arch if 'native' is specified. If system GPU
cannot be detected clang will fall back to the default GPU arch.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D139045
usage information in JSON to a file
Each line in the file is a JSON object that has the name of the main
source file followed by the list of system header files included
directly or indirectly from that file.
For example:
{"source":"/tmp/foo.c",
"includes":["/usr/include/stdio.h", "/usr/include/stdlib.h"]}
To reduce the amount of data written to the file, only the system
headers that are directly included from a non-system header file are
recorded.
In order to emit the header information in JSON, it is necessary to set
the following environment variables:
CC_PRINT_HEADERS_FORMAT=json CC_PRINT_HEADERS_FILTERING=only-direct-system
The following combination is equivalent to setting CC_PRINT_HEADERS=1:
CC_PRINT_HEADERS_FORMAT=textual CC_PRINT_HEADERS_FILTERING=none
Differential Revision: https://reviews.llvm.org/D137996
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Driver overwrites `DiagnosticsEngine::IgnoreAllWarnings` based on `-w` flag
without taking into account `DiagnosticOptions::IgnoreWarnings` that is
propagated to `DiagnosticsEngine` in `ProcessWarningOptions` (called from
`CompilerInstance::createDiagnostics`). It makes it hard to manipulate
`DiagnosticOptions` directly and pushes towards string-based API.
Most of in-tree tools use `DiagnosticOptions` already, so migrate
`clang_parseTranslationUnit_Impl` to use it too. Don't parse `-w`
directly but rely on
```
def w : Flag<["-"], "w">, HelpText<"Suppress all warnings">, Flags<[CC1Option]>,
MarshallingInfoFlag<DiagnosticOpts<"IgnoreWarnings">>;
```
Allows to reland D138252.
Differential Revision: https://reviews.llvm.org/D138970
Currently there is a -emit-header-module mode, which can combine several
headers together as a module interface. However, this breaks our
assumption (for standard c++ modules) about module interface. The module
interface should come from a module interface unit. And if it is a
header, it should be a header unit. And currently we have no ideas to
combine several headers together.
So I think this mode is an experimental one and it is not maintained and
it is not used. So it will be better to remove them.
Reviewed By: Bigcheese, dblaikie, bruno
Differential Revision: https://reviews.llvm.org/D137609
This patch allows users to configure clang with option
e.g. `-DCLANG_CONFIG_FILE_USER_DIR=~/.config/clang` or invoke clang
with `--config-user-dir=~/.config/clang`.
Patch merged on behalf of @paperchalice (LJC)
Differential Revision: https://reviews.llvm.org/D136940
Users may partition parameters specified by configuration file and put
different groups into separate files. These files are inserted into the
main file using constructs `@file`. Relative file names in it are
resolved relative to the including configuration file and this is not
convenient in some cases. A configuration file, which resides in system
directory, may need to include a file with user-defined parameters and
still provide default definitions if such file is absent.
To solve such problems, the option `--config=` is allowed inside
configuration files. Like `@file` it results in insertion of
command-line arguments but the algorithm of file search is different and
allows overriding system definitions with user ones.
Differential Revision: https://reviews.llvm.org/D136354
For `-foo=bar`, getSpelling return `-foo=` which is exactly what we need from
the diagnostic. Drop `-` from the err_drv_unsupported_option_argument template.
This change makes `--` long option diagnostics more convenient.
Reviewed By: lenary
Differential Revision: https://reviews.llvm.org/D137659
This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.