This moves code that sets the architecture name
and Float ABI into two new functions in
ToolChains/Arch/ARM.cpp. Greatly simplifying ComputeLLVMTriple.
Some light refactoring in setArchNameInTriple to
move local variables closer to their first use.
Reviewed By: ostannard
Differential Revision: https://reviews.llvm.org/D98253
Initially, this flag was meant to only be used through cc1 and not directly
through the clang driver. However, we accidentally ended up using this flag
as a driver flag already for selecting multilibs within the fuchsia toolchain.
We're currently in an awkward state where it's only accepted as a driver flag
when targeting Fuchsia, and all other instances it can only be added via
-Xclang. Since we're ready to use this in Fuchsia, we can just expose this to
the driver for simplicity.
Differential Revision: https://reviews.llvm.org/D98375
In -fno-exceptions -fno-asynchronous-unwind-tables -g0 mode,
GCC does not emit `.cfi_*` directives.
```
% diff <(gcc -fno-asynchronous-unwind-tables -dM -E a.c) <(gcc -dM -E a.c)
130a131
> #define __GCC_HAVE_DWARF2_CFI_ASM 1
```
This macro is useful because code can decide whether inline asm should include `.cfi_*` directives.
`.cfi_*` directives without `.cfi_startproc` can cause assembler errors
(integrated assembler: `this directive must appear between .cfi_startproc and .cfi_endproc directives`).
Differential Revision: https://reviews.llvm.org/D97743
By default, the driver uses the compiler-rt builtins and links with
-l:libunwind.a.
Restore the previous behavior by passing --rtlib=libgcc.
Reviewed By: danalbert
Differential Revision: https://reviews.llvm.org/D96404
In D97003, CUDA 9.2 is the minimum requirement for OpenMP offloading on
NVPTX target. We don't need to have macros in source code to select right functions
based on CUDA version. we don't need to compile multiple bitcode libraries of
different CUDA versions for each SM. We don't need to worry about future
compatibility with newer CUDA version.
`-target-feature +ptx61` is used in this patch, which corresponds to the highest
PTX version that CUDA 9.2 can support.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D97198
From `man ld`:
-why_load Log why each object file in a static library is loaded.
That is, what symbol was needed.
Also called -whyload for compatibility.
`-why_load` is the spelling preferred by the linker and `-whyload` an old
compatibility setting. clang should accept the preferred form, and map both
forms to the preferred form.
Differential Revision: https://reviews.llvm.org/D98156
Spack is a package management tool extensively used by HPC community.
As ROCm packages are built by Spack by HPC community, we need to teach
clang driver to detect ROCm installation built by Spack.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D97340
For MinGW targets, we distinguish between an explicitly shared unwinder
library (requested via -shared-libgcc), an explicitly static one
(requested via -static-libgcc or -static) and the default case (which
just passes -lunwind to the linker, which will pick either shared or
static depending on what's available, with the normal linker logic).
This makes the implicit default case (as added in D79995) actually work as
it was intended, when using the g++ driver (which is the main usecase for
libunwind as far as I know).
Differential Revision: https://reviews.llvm.org/D98023
A bug was introduced when adding -munsafe-fp-atomics.
By default it should be off.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D97967
Like nvptx and some other targets, -mconstructor-aliases does not work well with amdgpu,
therefore we disable it in the same approach.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D97959
Add support for the following Fortran dialect options:
- -default*
- -flarge-sizes
It also adds two test cases:
# For checking whether `flang-new` is passing options correctly to `flang-new -fc1`.
# For checking if `fdefault-` arguments are processed properly.
Also moves the Dialect related option parsing to a dedicated function
and adds a member `defaultKinds()` to `CompilerInvocation`
Depends on: D96032
Differential Revision: https://reviews.llvm.org/D96344
Adding it to the general filepaths results in it being added to the
linker arguments. The AIX linker always looks in this path anyway
and adds it as a default library path component. Adding this duplicate
explicitly results in duplicate entries in path in the loader section
of executables and messes up tools like CMake that parse the default
library flags.
Reviewed By: ZarkoCA
Differential Revision: https://reviews.llvm.org/D97574
Fix regression where we aren't passing `-platform_version` to new ld64.lld after {D95204}.
Most of the changes were originally in D95204, but I backed them out due to
test failures on builds which have `CLANG_DEFAULT_LINKER=lld`. The tests are
properly updated in this diff.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D97741
ccb4124a41 fixed translating -gz=zlib to --compress-debug-sections for
linker invocation for several ToolChains, but omitted FreeBSD.
Differential Revision: https://reviews.llvm.org/D97752
This makes CC1 and driver defaults consistent.
In addition, for more common cases (-g is specified without -gsplit-dwarf), users will not see -fno-split-dwarf-inlining in CC1 options.
Verified that the below is still true:
* `clang -g` => `splitDebugInlining: false` in DICompileUnit
* `clang -g -gsplit-dwarf` => `splitDebugInlining: false` in DICompileUnit
* `clang -g -gsplit-dwarf -fsplit-dwarf-inlining` => no `splitDebugInlining: false`
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D97706
The new Darwin backend for LLD is now able to link reasonably large
real-world programs on x86_64. For instance, we have achieved
self-hosting for the X86_64 target, where all LLD tests pass when
building lld with itself on macOS. As such, we would like to make it the
default back-end.
The new port is now named `ld64.lld`, and the old port remains
accessible as `ld64.lld.darwinold`
This [annoucement email][1] has some context. (But note that, unlike
what the email says, we are no longer doing this as part of the LLVM 12
branch cut -- instead we will go into LLVM 13.)
Numerous mechanical test changes were required to make this change; in
the interest of creating something that's reviewable on Phabricator,
I've split out the boring changes into a separate diff (D95905). I plan to
merge its contents with those in this diff before landing.
(@gkm made the original draft of this diff, and he has agreed to let me
take over.)
[1]: https://lists.llvm.org/pipermail/llvm-dev/2021-January/147665.html
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D95204
Added supporting CC_PRINT_PROC_STAT and CC_PRINT_PROC_STAT_FILE
environment variables to trigger clang driver reporting the process
statistics into specified file (alternate for -fproc-stat-report
option).
Differential Revision: https://reviews.llvm.org/D97094
When writing report file by option -proc-stat-report some part of output
can be written to unlocked file because destructor of raw_fd_ostream
calls `flush()`. In high thread contention environment it can result in
file operation failure. With this change `flush` is called explicitly when
file is locked, so call of `flush()` in the destructor does not cause
write to file.
These flags affect coverage mapping (-fcoverage-mapping), not
-fprofile-[instr-]generate so it makes more sense to use the
-fcoverage-* prefix.
Differential Revision: https://reviews.llvm.org/D97434
We introduce -ffile-compilation-dir shorthand to avoid having to set
-fdebug-compilation-dir and -fprofile-compilation-dir separately. This
is similar to -ffile-prefix-map.
Differential Revision: https://reviews.llvm.org/D97433
On Android, the unwinder isn't part of the C++ STL and isn't (in older
versions) exported from libc.so. Instead, the driver links the static
unwinder archive implicitly. Currently, the Android NDK implicitly
links libgcc.a to provide both builtins and the unwinder.
To support switching to compiler-rt builtins and libunwind, make
--rtlib=compiler-rt behave the same way on Android, and implicitly pass
-l:libunwind.a to the linker.
Adjust the -ldl logic. For the Android NDK, the unwinder (whether
libgcc.a or libunwind.a) is linked statically and calls a function in
the dynamic loader for finding unwind tables (e.g. dl_iterate_phdr).
On Android, this function is in libc.a for static executables and
libdl.so otherwise, so -ldl is needed. (glibc doesn't need -ldl because
its libc.so exports dl_iterate_phdr.)
Differential Revision: https://reviews.llvm.org/D96403
This fixes an issue where the toolchain discovery doesn't respect the
VFS's current working directory, specifically clangd not respecting a
relative /winsysroot.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D97437
The new `-fsanitize-address-destructor-kind=` option allows control over how module
destructors are emitted by ASan.
The new option is consumed by both the driver and the frontend and is propagated into
codegen options by the frontend.
Both the legacy and new pass manager code have been updated to consume the new option
from the codegen options.
It would be nice if the new utility functions (`AsanDtorKindToString` and
`AsanDtorKindFromString`) could live in LLVM instead of Clang so they could be
consumed by other language frontends. Unfortunately that doesn't work because
the clang driver doesn't link against the LLVM instrumentation library.
rdar://71609176
Differential Revision: https://reviews.llvm.org/D96572
This patch makes sure that for the following invocation of the new Flang
driver, clangDriver sets the input type to Fortran:
```
flang-new -E -
```
This change does not affect `clang`, i.e. for the following invocation
the input type is set to C:
```
clang -E -
```
This change leverages the fact that for `flang-new` the driver is in
Flang mode.
Differential Revision: https://reviews.llvm.org/D96777
There are two preconditions to reproduce the issue,
1. Use -save-temps option
2. Provide the -o option with name equal to the input file name
without the file extension. For e.g. clang a.c -o a
With the -o specified, the AssembleJobAction after OffloadWrapperJobAction
will produce the object file with same name as host code object file.
Due to this clash, the OffloadWrapperAction overwrites the initial host
object file, which results in lld error. This also fixes the `multiple definition of __dummy.omp_offloading.entry'` issue in D96769 .
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D97273
When targeting a MSVC triple, --dependant-libs with the name of the clang runtime library for profiling is added to the command line args. In it's current implementations clang_rt.profile-<ARCH> is chosen as the name. When building a distribution using LLVM_ENABLE_PER_TARGET_RUNTIME_DIR this fails, due to the runtime file names not having an architecture suffix in the filename.
This patch refactors getCompilerRT and getCompilerRTBasename to always consider per-target runtime directories. getCompilerRTBasename now simply returns the filename component of the path found by getCompilerRT
Differential Revision: https://reviews.llvm.org/D96638
In current implementation of `deviceRTLs`, we're using some functions
that are CUDA version dependent (if CUDA_VERSION < 9, it is one; otheriwse, it
is another one). As a result, we have to compile one bitcode library for each
CUDA version supported. A worse problem is forward compatibility. If a new CUDA
version is released, we have to update CMake file as well.
CUDA 9.2 has been released for three years. Instead of using various weird tricks
to make `deviceRTLs` work with different CUDA versions and still have forward
compatibility, we can simply drop support for CUDA 9.1 or lower version. It has at
least two benifits:
- We don't need to generate bitcode libraries for each CUDA version;
- Clang driver doesn't need to search for the bitcode lib based on CUDA version.
We can claim that starting from LLVM 12, OpenMP offloading on NVPTX target requires
CUDA 9.2+.
Reviewed By: jdoerfert, JonChesterfield
Differential Revision: https://reviews.llvm.org/D97003
This change enables the builtin function declarations
in clang driver by default using the Tablegen solution
along with the implicit include of 'opencl-c-base.h'
header.
A new flag '-cl-no-stdinc' disabling all default
declarations and header includes is added. If any other
mechanisms were used to include the declarations (e.g.
with -Xclang -finclude-default-header) and the new default
approach is not sufficient the, `-cl-no-stdinc` flag has
to be used with clang to activate the old behavior.
Tags: #clang
Differential Revision: https://reviews.llvm.org/D96515
This patch adds support for `-Xflang` in `flang-new`. The semantics are
identical to `-Xclang`.
With the addition of `-Xflang`, we can modify `-test-io` to be a
compiler-frontend only flag. This makes more sense, this flag is:
* very frontend specific
* to be used for development and testing only
* not to be exposed to the end user
Originally we added it to the compiler driver, `flang-new`, in order to
facilitate testing. With `-Xflang` this is no longer needed. Tests are
updated accordingly.
Differential Revision: https://reviews.llvm.org/D96864
This patch moves the creation of the '-Wspir-compat' argument from cc1 to the driver.
Without this change, generating command line arguments from `CompilerInvocation` cannot be done reliably: there's no way to distinguish whether '-Wspir-compat' was passed to cc1 on the command line (should be generated), or if it was created within `CompilerInvocation::CreateFromArgs` (should not be generated).
This is also in line with how other '-W' flags are handled.
(This was introduced in D21567.)
Reviewed By: Anastasia
Differential Revision: https://reviews.llvm.org/D97041
Add option -fgpu-sanitize to enable sanitizer for AMDGPU target.
Since it is experimental, it is off by default.
Reviewed by: Artem Belevich
Differential Revision: https://reviews.llvm.org/D96835
We currently always store absolute filenames in coverage mapping. This
is problematic for several reasons. It poses a problem for distributed
compilation as source location might vary across machines. We are also
duplicating the path prefix potentially wasting space.
This change modifies how we store filenames in coverage mapping. Rather
than absolute paths, it stores the compilation directory and file paths
as given to the compiler, either relative or absolute. Later when
reading the coverage mapping information, we recombine relative paths
with the working directory. This approach is similar to handling
ofDW_AT_comp_dir in DWARF.
Finally, we also provide a new option, -fprofile-compilation-dir akin
to -fdebug-compilation-dir which can be used to manually override the
compilation directory which is useful in distributed compilation cases.
Differential Revision: https://reviews.llvm.org/D95753
Arnamoy Bhattacharyya