The driver uses class SanitizerArgs to store parsed sanitizer arguments. It keeps a cached
SanitizerArgs object in ToolChain and uses it for different jobs. This does not work if
the sanitizer options are different for different jobs, which could happen when an
offloading toolchain translates the options for different jobs.
To fix this, SanitizerArgs should be created by using the actual arguments passed
to jobs instead of the original arguments passed to the driver, since the toolchain
may change the original arguments. And the sanitizer arguments should be diagnose
once.
This patch also fixes HIP toolchain for handling -fgpu-sanitize: a warning is emitted
for GPU's not supporting sanitizer and skipped. This is for backward compatibility
with existing -fsanitize options. -fgpu-sanitize is also turned on by default.
Reviewed by: Artem Belevich, Evgenii Stepanov
Differential Revision: https://reviews.llvm.org/D111443
This reverts commit 2d7fba5f95.
The patch was reverted because it caused regression with rocThrust
due to ambiguity of template specialization.
For details please see https://reviews.llvm.org/D109496
A resolution to the ambiguity issues created by P0522, which is a DR solving
CWG 150, did not come as expected, so we are just going to accept the change,
and watch how users digest it.
For now we deprecate the flag with a warning, and make it on by default.
We don't remove the flag completely in order to give users a chance to
work around any problems by disabling it.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D109496
An archive containing device code object files can be passed to
clang command line for linking. For each given offload target
it creates a device specific archives which is either passed to llvm-link
if the target is amdgpu, or to clang-nvlink-wrapper if the target is
nvptx. -L/-l flags are used to specify these fat archives on the command
line. E.g.
clang++ -fopenmp -fopenmp-targets=nvptx64 main.cpp -L. -lmylib
It currently doesn't support linking an archive directly, like:
clang++ -fopenmp -fopenmp-targets=nvptx64 main.cpp libmylib.a
Linking with x86 offload also does not work.
Reviewed By: ye-luo
Differential Revision: https://reviews.llvm.org/D105191
An archive containing device code object files can be passed to
clang command line for linking. For each given offload target
it creates a device specific archives which is either passed to llvm-link
if the target is amdgpu, or to clang-nvlink-wrapper if the target is
nvptx. -L/-l flags are used to specify these fat archives on the command
line. E.g.
clang++ -fopenmp -fopenmp-targets=nvptx64 main.cpp -L. -lmylib
It currently doesn't support linking an archive directly, like:
clang++ -fopenmp -fopenmp-targets=nvptx64 main.cpp libmylib.a
Linking with x86 offload also does not work.
Reviewed By: ye-luo
Differential Revision: https://reviews.llvm.org/D105191
Given D109057, change test runner to use the libomptarget-x-bc-path
argument instead of the LIBRARY_PATH environment variable to find the device
library.
Also drop the use of LIBRARY_PATH environment variable as it is far
too easy to pull in the device library from an unrelated toolchain by accident
with the current setup. No loss in flexibility to developers as the clang
commandline used here is still available.
Reviewed By: jdoerfert, tianshilei1992
Differential Revision: https://reviews.llvm.org/D109061
Now prints the list of known archs. This requires plumbing a Driver
arg through a few functions.
Also add two more convenience insert() overlods to StringMap.
Differential Revision: https://reviews.llvm.org/D109105
The commandline flag to specify a particular openmp devicertl library
currently errors like:
```
fatal error: cannot open file
'./runtimes/runtimes-bins/openmp/libomptarget':
Is a directory
```
CommonArgs successfully appends the directory to the commandline args then
mlink-builtin-bitcode rejects it.
This patch is a point fix to that. If --libomptarget-amdgcn-bc-path=directory
then append the expected name for the current architecture and go on as before.
This is useful for test runners that don't hardcode the architecture.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D109057
Given D109057, change test runner to use the libomptarget-x-bc-path
argument instead of the LIBRARY_PATH environment variable to find the device
library.
Also drop the use of LIBRARY_PATH environment variable as it is far
too easy to pull in the device library from an unrelated toolchain by accident
with the current setup. No loss in flexibility to developers as the clang
commandline used here is still available.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D109061
The commandline flag to specify a particular openmp devicertl library
currently errors like:
```
fatal error: cannot open file
'./runtimes/runtimes-bins/openmp/libomptarget':
Is a directory
```
CommonArgs successfully appends the directory to the commandline args then
mlink-builtin-bitcode rejects it.
This patch is a point fix to that. If --libomptarget-amdgcn-bc-path=directory
then append the expected name for the current architecture and go on as before.
This is useful for test runners that don't hardcode the architecture.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D109057
Code added by D106688 has a problem. It passes the option -bxyz to the system linker as -b xyz xyz (duplication of the string 'xyz' is incorrect). This patch fixes that oversight.
Reviewed by: hubert.reinterpretcast, jsji
Differential Revision: https://reviews.llvm.org/D107786
This patch will re-enable the patch posted under https://reviews.llvm.org/D106688 originally which was reverted due to buildbreak that was caused by mismatched diagnostic message arguments.
Reviewed By: Zarko Todorovski
Differential Revision: https://reviews.llvm.org/D107105
Parse the -b option in the driver and pass it to the linker if the target OS is AIX. This will establish compatibility with the other AIX compilers.
Reviewed By: Zarko Todorovski
Differential Revision: https://reviews.llvm.org/D106688
Summary:
Set the TargetCPUName for AIX to default to pwr7, removing the setting
of it based on the major/minor of the OS version, which previously
set it to pwr4 for AIX 7.1 and earlier. The old code would also set it to
pwr4 when the OS version was not specified and with the change, it will
default it to pwr7 in all cases.
Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By:hubert.reinterpretcast (Hubert Tong)
Differential Revision: https://reviews.llvm.org/D107063
Moving `InputInfo.h` from `lib/Driver/` into `include/Driver` to be able to expose it in an API consumed from outside of `clangDriver`.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D106787
Summary:
AIX does not support --as-needed linker options. Remove that option from
aix linker when -lunwind is needed.
For unwinder library, nothing special is needed because by default aix
linker has the as-needed effect for library that's an archive (which is
the case for libunwind on AIX).
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D104314
Summary:
We are going to have libc++abi.a and libunwind.a on AIX.
Add the necessary linking command to pick the libraries up.
Reviewed By: daltenty
Differential Revision: https://reviews.llvm.org/D102813
This reverts commit 6911114d8c.
Broke the QEMU sanitizer bots due to a missing header dependency. This
actually needs to be fixed on the bot-side, but for now reverting this
patch until I can fix up the bot.
This patch moves -fsanitize=scudo to link the standalone scudo library,
rather than the original compiler-rt based library. This is one of the
major remaining roadblocks to deleting the compiler-rt based scudo,
which should not be used any more. The standalone Scudo is better in
pretty much every way and is much more suitable for production usage.
As well as patching the litmus tests for checking that the
scudo_standalone lib is linked instead of the scudo lib, this patch also
ports all the scudo lit tests to run under scudo standalone.
This patch also adds a feature to scudo standalone that was under test
in the original scudo - that arguments passed to an aligned operator new
were checked that the alignment was a power of two.
Some lit tests could not be migrated, due to the following issues:
1. Features that aren't supported in scudo standalone, like the rss
limit.
2. Different quarantine implementation where the test needs some more
thought.
3. Small bugs in scudo standalone that should probably be fixed, like
the Secondary allocator having a full page on the LHS of an allocation
that only contains the chunk header, so underflows by <= a page aren't
caught.
4. Slight differences in behaviour that's technically correct, like
'realloc(malloc(1), 0)' returns nullptr in standalone, but a real
pointer in old scudo.
5. Some tests that might be migratable, but not easily.
Tests that are obviously not applicable to scudo standalone (like
testing that no sanitizer symbols made it into the DSO) have been
deleted.
After this patch, the remaining work is:
1. Update the Scudo documentation. The flags have changed, etc.
2. Delete the old version of scudo.
3. Patch up the tests in lit-unmigrated, or fix Scudo standalone.
Reviewed By: cryptoad, vitalybuka
Differential Revision: https://reviews.llvm.org/D102543
Since we have both aliasing mode and Intel LAM on x86_64, we need to
choose the mode at either run time or compile time. This patch
implements the plumbing to build both and choose between them at
compile time.
Reviewed By: vitalybuka, eugenis
Differential Revision: https://reviews.llvm.org/D102286
[clang][amdgpu] Use implicit code object version
At present, clang always passes amdhsa-code-object-version on to -cc1. That is
great for certainty over what object version is being used when debugging.
Unfortunately, the command line argument is in AMDGPUBaseInfo.cpp in the amdgpu
target. If clang is used with an llvm compiled with DLLVM_TARGETS_TO_BUILD
that excludes amdgpu, this will be diagnosed (as discovered via D98658):
- Unknown command line argument '--amdhsa-code-object-version=4'
This means that clang, built only for X86, can be used to compile the nvptx
devicertl for openmp but not the amdgpu one. That would shortly spawn fragile
logic in the devicertl cmake to try to guess whether the clang used will work.
This change omits the amdhsa-code-object-version parameter when it matches the
default that AMDGPUBaseInfo.cpp specifies, with a comment to indicate why. As
this is the only part of clang's codegen for amdgpu that depends on the target
in the back end it suffices to build the openmp runtime on most (all?) systems.
It is a non-functional change, though observable in the updated tests and when
compiling with -###. It may cause minor disruption to the amd-stg-open branch.
Revision of D98746, builds on refactor in D101077
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D101095
[clang][nfc] Split getOrCheckAMDGPUCodeObjectVersion
Separates detection of deprecated or invalid code object version from
returning the version. Written to avoid any behaviour change.
Precursor to a revision of D98746.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D101077
Based on this debugger type, for now, we plan to:
1: use inline string by default for XCOFF DWARF
2: generate no column info for debug line table.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D99400
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
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
Drop the `Separate` form of `-fmodule-name X`, `-fprofile-remapping-file X`, and `-frewrite-map-file X`.
To the best of my knowledge they are not used. Their conventional Joined forms (`-fFOO=`) should be used instead.
`-fdebug-compilation-dir X` is used in several places, e.g. chromium/infra/goma.
It is also advertised in http://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html
So we keep it but make the EQ form canonical and the Separate form an alias.
Differential Revision: https://reviews.llvm.org/D96886
This patch uses the existing logic of CUDA for searching libomptarget
and extracts it to a common method.
Reviewed By: JonChesterfield, tianshilei1992
Differential Revision: https://reviews.llvm.org/D96248
This patch propagates the -moutline flag when LTO is enabled and avoids
passing it explicitly to the linker plugin.
Differential Revision: https://reviews.llvm.org/D93385
Add powerpcle support to clang.
For FreeBSD, assume a freestanding environment for now, as we only need it in the first place to build loader, which runs in the OpenFirmware environment instead of the FreeBSD environment.
For Linux, recognize glibc and musl environments to match current usage in Void Linux PPC.
Adjust driver to match current binutils behavior regarding machine naming.
Adjust and expand tests.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D93919
[amdgpu] Default to code object v3
v4 is not yet readily available, and doesn't appear
to be implemented in the back end
Reviewed By: t-tye, yaxunl
Differential Revision: https://reviews.llvm.org/D93258
[amdgpu] Default to code object v3
v4 is not yet readily available, and doesn't appear
to be implemented in the back end
Reviewed By: t-tye
Differential Revision: https://reviews.llvm.org/D93258
The new PM is considered stable and many downstream groups have adopted it (some
have adopted it for more than two years). Add -f[no-]legacy-pass-manager to reflect the
fact that it is no longer experimental and the legacy pass manager is something we strive to retire.
In the future, when the legacy PM eventually goes away,
-fno-experimental-new-pass-manager and -flegacy-pass-manager will be removed.
This patch also changes -f[no-]legacy-pass-manager to pass `-plugin-opt={new,legacy}-pass-manager` to the linker (supported by both ld.lld and LLVMgold.so) when -flto/-flto=thin is specified
Reviewed By: aeubanks, rsmith
Differential Revision: https://reviews.llvm.org/D92915
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.
Rename it internally to LLVM_ENABLE_NEW_PASS_MANAGER.
The #define for it is now in llvm-config.h.
The initial land accidentally set the value of
LLVM_ENABLE_NEW_PASS_MANAGER to the string
ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER instead of its value.
Reviewed By: rnk, hans
Differential Revision: https://reviews.llvm.org/D92072
This allows us to use its value everywhere, rather than just clang. Some
other places, like opt and lld, will use its value soon.
The #define for it is now in llvm-config.h.
Reviewed By: rnk, hans
Differential Revision: https://reviews.llvm.org/D92072
Summary:
Propagate driver commandline remarks options to linker when LTO is enabled.
This gives novice user a convenient way to collect and filter remarks throughout
a typical toolchain invocation with sample profile and LTO using single switch
from the clang driver.
A typical use of this option from clang command-line:
* Using -Rpass* options to print remarks to screen:
clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt
-Rpass=inline -Rpass-missed=inline -Rpass-analysis=inline
-fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp
Remarks will be dumped to screen from both pre-lto and lto
compilation.
* Using serialized remarks options
clang -fuse-ld=lld -flto=thin -fprofile-sample-use=foo_sample.txt
-fsave-optimization-record
-fdiagnostics-show-hotness -fdiagnostics-hotness-threshold=100 -o foo foo.cpp
This will produce multiple yaml files containing optimization remarks:
1. foo.opt.yaml : remarks from pre-lto
2. foo.opt.ld.yaml.thin.1.yaml: remark during lto
Differential Revision: https://reviews.llvm.org/D85810
Summary:
Makes linking the sanitizers follow the same logic as the rest of the
driver with respect to the static linking strategy for the C++ standard
library.
Subscribers: mcrosier, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80488
Object of class `Command` contains various properties of a command to
execute, but output file was missed from them. This change adds this
property. It is required for reporting consumed time and memory implemented
in D78903 and may be used in other cases too.
Differential Revision: https://reviews.llvm.org/D78902
recommit e50465ecef with fix for
regression in lldb tests.
Two issues:
1. the directory part of original .dwo file was dropped
2. if the stem of the .dwo file contains '.', the last dot
and strings after that were removed
This recommit fixes those two issues.
when -gsplit option is used with clang driver, clang driver will create
a filename with .dwo option based on the input file name and pass
it to clang -cc1. This file is used for storing the debug info. Since
HIP generate separate object files for different GPU arch's,
this file should be different for different GPU arch. This patch
adds _ and GPU arch to the stem of the dwo file.
Differential Revision: https://reviews.llvm.org/D87791
This is consistent with the clang option added in
7ed8124d46, and the comments on the
runtime patch in D87120.
Differential Revision: https://reviews.llvm.org/D87622
gcc translates -gz=zlib to --compress-debug-options=zlib for both assembler and linker
but clang only does this for assembler.
The linker needs --compress-debug-options=zlib option to compress the debug sections
in the generated executable or shared library.
Due to this bug, -gz=zlib has no effect on the generated executable or shared library.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D87321
As reported in Bug 42535, `clang` doesn't inline atomic ops on 32-bit
Sparc, unlike `gcc` on Solaris. In a 1-stage build with `gcc`, only two
testcases are affected (currently `XFAIL`ed), while in a 2-stage build more
than 100 tests `FAIL` due to this issue.
The reason for this `gcc`/`clang` difference is that `gcc` on 32-bit
Solaris/SPARC defaults to `-mpcu=v9` where atomic ops are supported, unlike
with `clang`'s default of `-mcpu=v8`. This patch changes `clang` to use
`-mcpu=v9` on 32-bit Solaris/SPARC, too.
Doing so uncovered two bugs:
`clang -m32 -mcpu=v9` chokes with any Solaris system headers included:
/usr/include/sys/isa_defs.h:461:2: error: "Both _ILP32 and _LP64 are defined"
#error "Both _ILP32 and _LP64 are defined"
While `clang` currently defines `__sparcv9` in a 32-bit `-mcpu=v9`
compilation, neither `gcc` nor Studio `cc` do. In fact, the Studio 12.6
`cc(1)` man page clearly states:
These predefinitions are valid in all modes:
[...]
__sparcv8 (SPARC)
__sparcv9 (SPARC -m64)
At the same time, the patch defines `__GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248]`
for a 32-bit Sparc compilation with any V9 cpu. I've also changed
`MaxAtomicInlineWidth` for V9, matching what `gcc` does and the Oracle
Developer Studio 12.6: C User's Guide documents (Ch. 3, Support for Atomic
Types, 3.1 Size and Alignment of Atomic C Types).
The two testcases that had been `XFAIL`ed for Bug 42535 are un-`XFAIL`ed
again.
Tested on `sparcv9-sun-solaris2.11` and `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D86621
This CL modifies clang enabling using -fsanitize=thread on fuchsia. The
change doesn't build the runtime for fuchsia, it just enables the
instrumentation to be used.
pair-programmed-with: mdempsky@google.com
Change-Id: I816c4d240d1f15e9eae2803fb8ba3a7bf667ed51
Reviewed By: mcgrathr, phosek
Differential Revision: https://reviews.llvm.org/D86822
See RFC for background:
http://lists.llvm.org/pipermail/llvm-dev/2020-June/142744.html
Note that the runtime changes will be sent separately (hopefully this
week, need to add some tests).
This patch includes the LLVM pass to instrument memory accesses with
either inline sequences to increment the access count in the shadow
location, or alternatively to call into the runtime. It also changes
calls to memset/memcpy/memmove to the equivalent runtime version.
The pass is modeled on the address sanitizer pass.
The clang changes add the driver option to invoke the new pass, and to
link with the upcoming heap profiling runtime libraries.
Currently there is no attempt to optimize the instrumentation, e.g. to
aggregate updates to the same memory allocation. That will be
implemented as follow on work.
Differential Revision: https://reviews.llvm.org/D85948
`ninja check-all` currently fails on Illumos:
[84/716] Generating default/Asan-i386-inline-Test
FAILED: projects/compiler-rt/lib/asan/tests/default/Asan-i386-inline-Test
cd /var/llvm/dist-amd64-release/projects/compiler-rt/lib/asan/tests && /var/llvm/dist-amd64-release/./bin/clang ASAN_INST_TEST_OBJECTS.gtest-all.cc.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_globals_test.cpp.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_interface_test.cpp.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_internal_interface_test.cpp.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_test.cpp.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_oob_test.cpp.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_mem_test.cpp.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_str_test.cpp.i386-inline.o ASAN_INST_TEST_OBJECTS.asan_test_main.cpp.i386-inline.o -o /var/llvm/dist-amd64-release/projects/compiler-rt/lib/asan/tests/default/./Asan-i386-inline-Test -g --driver-mode=g++ -fsanitize=address -m32
ld: fatal: unrecognized option '--no-as-needed'
ld: fatal: use the -z help option for usage information
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)
`clang` unconditionally passes `--as-needed`/`--no-as-needed` to the
linker. This works on Solaris 11.[34] which added a couple of option
aliases to the native linker to improve compatibility with GNU `ld`.
Illumos `ld` didn't do this, so one needs to use the corresponding
native options `-z ignore`/`-z record` instead.
Because this works on both Solaris and Illumos, the current patch always
passes the native options on Solaris. This isn't fully correct, however:
when using GNU `ld` on Solaris (not yet supported; I'm working on that),
one still needs `--as-needed` instead.
I'm hardcoding this decision because a generic detection via a `cmake` test
is hard: many systems have their own implementation of `getDefaultLinker`
and `cmake` would have to duplicate the information encoded there.
Besides, it would still break when `-fuse-ld` is used.
Tested on `amd64-pc-solaris2.11` (Solaris 11.4 and OpenIndiana 2020.04),
`sparcv9-sun-solaris2.11`, and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D84412
Summary: libFuzzer intercepts certain library functions such as memcmp/strcmp by defining weak hooks. Weak hooks, however, are called only when other runtimes such as ASan is linked. This patch defines libFuzzer's own interceptors, which is linked into the libFuzzer executable when other runtimes are not linked, i.e., when -fsanitize=fuzzer is given, but not others.
The patch once landed but was reverted in 8ef9e2bf35 due to an assertion failure caused by calling an intercepted function, strncmp, while initializing the interceptors in fuzzerInit(). This issue is now fixed by calling libFuzzer's own implementation of library functions (i.e., internal_*) when the fuzzer has not been initialized yet, instead of recursively calling fuzzerInit() again.
Reviewers: kcc, morehouse, hctim
Subscribers: #sanitizers, krytarowski, mgorny, cfe-commits
Tags: #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D83494
This causes binaries linked with this runtime to crash on startup if
dlsym uses any of the intercepted functions. (For example, that happens
when using tcmalloc as the allocator: dlsym attempts to allocate memory
with malloc, and tcmalloc uses strncmp within its implementation.)
Also revert dependent commit "[libFuzzer] Disable implicit builtin knowledge about memcmp-like functions when -fsanitize=fuzzer-no-link is given."
This reverts commit f78d9fceea and 12d1124c49.
Summary: libFuzzer intercepts certain library functions such as memcmp/strcmp by defining weak hooks. Weak hooks, however, are called only when other runtimes such as ASan is linked. This patch defines libFuzzer's own interceptors, which is linked into the libFuzzer executable when other runtimes are not linked, i.e., when -fsanitize=fuzzer is given, but not others.
Reviewers: kcc, morehouse, hctim
Reviewed By: morehouse, hctim
Subscribers: krytarowski, mgorny, cfe-commits, #sanitizers
Tags: #clang, #sanitizers
Differential Revision: https://reviews.llvm.org/D83494
Summary:
1. gcc uses `-march` and `-mtune` flag to chose arch and
pipeline model, but clang does not have `-mtune` flag,
we uses `-mcpu` to chose both infos.
2. Add SiFive e31 and u54 cpu which have default march
and pipeline model.
3. Specific `-mcpu` with rocket-rv[32|64] would select
pipeline model only, and use the driver's arch choosing
logic to get default arch.
Reviewers: lenary, asb, evandro, HsiangKai
Reviewed By: lenary, asb, evandro
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D71124
specified at Command creation, rather than as part of the Tool.
This resolves the hack I just added to allow Darwin toolchain to vary
its level of support based on `-mlinker-version=`.
The change preserves the _current_ settings for response-file support.
Some tools look likely to be declaring that they don't support
response files in error, however I kept them as-is in order for this
change to be a simple refactoring.
Differential Revision: https://reviews.llvm.org/D82782
This patch is a follow up on https://reviews.llvm.org/D78759.
Extract the HIP Linker script from generic GNU linker,
and move it into HIP ToolChain. Update OffloadActionBuilder
Link actions feature to apply device linking and host linking
actions separately. Using MC Directives, embed the device images
and define symbols.
Reviewers: JonChesterfield, yaxunl
Subscribers: tra, echristo, jdoerfert, msearles, scchan
Differential Revision: https://reviews.llvm.org/D81963
Summary: This patch removes the special handling for Darwin on PowerPC in the default target cpu handling, because Darwin is no longer supported on the PowerPC platform.
Reviewers: hubert.reinterpretcast, daltenty
Reviewed By: hubert.reinterpretcast
Subscribers: wuzish, nemanjai, shchenz, steven.zhang, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81115
Summary: This patch changes the AIX default target CPU to power4 since this is the the lowest arch for the lowest OS level supported.
Reviewers: hubert.reinterpretcast, cebowleratibm, daltenty
Reviewed By: hubert.reinterpretcast
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80835
Summary: Before this patch, we use two different ways to pass options to align branch
depending on whether LTO is enabled. For example, `-mbranches-within-32B-boundaries`
w/o LTO and `-Wl,-plugin-opt=-x86-branches-within-32B-boundaries` w/ LTO. It's
inconvenient, so this patch unifies the way: we only need to pass options like
`-mbranches-within-32B-boundaries` to align branches, no matter LTO is enabled or not.
Differential Revision: https://reviews.llvm.org/D80289
Fixes PR42445 (compiler driver options -Os -Oz translate to
-plugin-opt=Os (Oz) which are not recognized by LLVMgold.so or LLD).
The optimization level mapping matches
CompilerInvocation.cpp:getOptimizationLevel() and SpeedLevel of
PassBuilder::OptimizationLevel::O*.
-plugin-opt=O* affects the way we construct regular LTO/ThinLTO pass
manager pipeline.
Reviewed By: pcc
Differential Revision: https://reviews.llvm.org/D79919
Before this patch, it wasn't possible to extend the ThinLTO threads to all SMT/CMT threads in the system. Only one thread per core was allowed, instructed by usage of llvm::heavyweight_hardware_concurrency() in the ThinLTO code. Any number passed to the LLD flag /opt:lldltojobs=..., or any other ThinLTO-specific flag, was previously interpreted in the context of llvm::heavyweight_hardware_concurrency(), which means SMT disabled.
One can now say in LLD:
/opt:lldltojobs=0 -- Use one std::thread / hardware core in the system (no SMT). Default value if flag not specified.
/opt:lldltojobs=N -- Limit usage to N threads, regardless of usage of heavyweight_hardware_concurrency().
/opt:lldltojobs=all -- Use all hardware threads in the system. Equivalent to /opt:lldltojobs=$(nproc) on Linux and /opt:lldltojobs=%NUMBER_OF_PROCESSORS% on Windows. When an affinity mask is set for the process, threads will be created only for the cores selected by the mask.
When N > number-of-hardware-threads-in-the-system, the threads in the thread pool will be dispatched equally on all CPU sockets (tested only on Windows).
When N <= number-of-hardware-threads-on-a-CPU-socket, the threads will remain on the CPU socket where the process started (only on Windows).
Differential Revision: https://reviews.llvm.org/D75153
AddGoldPlugin does more than adding `-plugin path/to/LLVMgold.so`.
It works with lld and GNU ld, and adds other LTO options.
So AddGoldPlugin is no longer a suitable name.
Reviewed By: tejohnson
Differential Revision: https://reviews.llvm.org/D74591
This is never appropriate on Fuchsia and any future needs for
system library dependencies of compiler-supplied runtimes will
be addressed via .deplibs instead of driver hacks.
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D73734
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
Currently device lib path set by environment variable HIP_DEVICE_LIB_PATH
does not work due to extra "-L" added to each entry.
This patch fixes that by allowing argument name to be empty in addDirectoryList.
Differential Revision: https://reviews.llvm.org/D73299
This required some fixes to the generic code for two issues:
1. -fsanitize=safe-stack is default on x86_64-fuchsia and is *not* incompatible with -fsanitize=leak on Fuchisa
2. -fsanitize=leak and other static-only runtimes must not be omitted under -shared-libsan (which is the default on Fuchsia)
Patch By: mcgrathr
Differential Revision: https://reviews.llvm.org/D73397
In the GNU toolchain, `-static-libgcc` implies that the unwindlib will
be linked statically. However, when `--unwindlib=libunwind`, this flag is
ignored, and a bare `-lunwind` is added to the linker args. Unfortunately,
this means that if both `libunwind.so`, and `libunwind.a` are present
in the library path, `libunwind.so` will be chosen in all cases where
`-static` is not set.
This change makes `-static-libgcc` affect the `-l` flag produced by
`--unwindlib=libunwind`. After this patch, providing
`-static-libgcc --unwindlib=libunwind` will cause the driver to explicitly
emit `-l:libunwind.a` to statically link libunwind. For all other cases
it will emit `-l:libunwind.so` matching current behavior with a more
explicit link line.
https://reviews.llvm.org/D70416
This started passing target-features on the linker line, not just for RISCV but
for all targets, leading to error messages in Chromium Android build:
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
'+soft-float-abi' is not a recognized feature for this target (ignoring feature)
See Phabricator review for details.
Reverting until this can be fixed properly.
> Summary:
> 1. enable LTO need to pass target feature and abi to LTO code generation
> RISCV backend need the target feature to decide which extension used in
> code generation.
> 2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
> 3. add general tools::getTargetABI in CommonArgs.h because different target uses different
> way to get the target ABI.
>
> Patch by Kuan Hsu Chen (khchen)
>
> Reviewers: lenary, lewis-revill, asb, MaskRay
>
> Reviewed By: lenary
>
> Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D67409
This flag decouples specifying the DWARF version from enabling/disabling
DWARF in general (or the gN level - gmlt/limited/standalone, etc) while
still allowing existing -gdwarf-N flags to override this default.
Patch by Caroline Tice!
Differential Revision: https://reviews.llvm.org/D69822
Summary:
1. enable LTO need to pass target feature and abi to LTO code generation
RISCV backend need the target feature to decide which extension used in
code generation.
2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag
3. add general tools::getTargetABI in CommonArgs.h because different target uses different
way to get the target ABI.
Patch by Kuan Hsu Chen (khchen)
Reviewers: lenary, lewis-revill, asb, MaskRay
Reviewed By: lenary
Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67409
llvm-svn: 374774
This patch removes the remaining part of the OpenMP offload linker scripts which was used for inserting device binaries into the output linked binary. Device binaries are now inserted into the host binary with a help of the wrapper bit-code file which contains device binaries as data. Wrapper bit-code file is dynamically created by the clang driver with a help of new tool clang-offload-wrapper which takes device binaries as input and produces bit-code file with required contents. Wrapper bit-code is then compiled to an object and resulting object is appended to the host linking by the clang driver.
This is the second part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943).
Differential Revision: https://reviews.llvm.org/D68166
llvm-svn: 374219
Currently clang does not save some of the intermediate file generated during device compilation for HIP when -save-temps is specified.
This patch fixes that.
Differential Revision: https://reviews.llvm.org/D68665
llvm-svn: 374198
Linker automatically provides __start_<section name> and __stop_<section name> symbols to satisfy unresolved references if <section name> is representable as a C identifier (see https://sourceware.org/binutils/docs/ld/Input-Section-Example.html for details). These symbols indicate the start address and end address of the output section respectively. Therefore, renaming OpenMP offload entries section name from ".omp.offloading_entries" to "omp_offloading_entries" to use this feature.
This is the first part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943).
Differential Revision: https://reviews.llvm.org/D68070
llvm-svn: 373118
Summary:
Appease failed builds (due to -Werror and -Wswitch) where OMPRT_Unknown
is not handled in the switch statement (even though it's handled by the
early exit).
This fixes -Wswitch triggered by r371442.
Reviewers: srhines, danalbert, jdoerfert
Subscribers: guansong, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67364
llvm-svn: 371444
Summary:
For Gnu, FreeBSD and NetBSD, this option forces linking with the static
OpenMP host runtime (similar to -static-libgcc and -static-libstdcxx).
Android's NDK will start the shared OpenMP runtime in addition to the static
libomp. In this scenario, the linker will prefer to use the shared library by
default. Add this option to enable linking with the static libomp.
Reviewers: Hahnfeld, danalbert, srhines, joerg, jdoerfert
Subscribers: guansong, cfe-commits
Tags: #clang
Fixes https://github.com/android-ndk/ndk/issues/1028
Differential Revision: https://reviews.llvm.org/D67200
llvm-svn: 371437
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
Yaxun (Sam) Liu