These are GCC-compatible multilibs that use the generic Itanium C++ ABI
instead of the Fuchsia C++ ABI.
Differential Revision: https://reviews.llvm.org/D102030
When using the per-target runtime build, it may be desirable to have
different __config_site headers for each target where all targets cannot
share a single configuration.
The layout used for libc++ headers after this change is:
```
include/
c++/
v1/
<libc++ headers except for __config_site>
<target1>/
c++/
v1/
__config_site
<target2>/
c++/
v1/
__config_site
<other targets>
```
This is the most optimal layout since it avoids duplication, the only
headers that's per-target is __config_site, all other headers are
shared across targets. This also means that we no need two
-isystem flags: one for the target-agnostic headers and one for
the target specific headers.
Differential Revision: https://reviews.llvm.org/D89013
This is a partial revert of b4537c3f51
based on the discussion in https://reviews.llvm.org/D101194. Rather
than using the getMultiarchTriple, we use the getTripleString.
- Unsupported Windows to drop backslashes code
- Upgrade to current gcc 10 version
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101347
This is a follow-up of e92d2b80c6 ("[Driver] Detect libstdc++ include
paths for native gcc (-m32 and -m64) on Debian i386") for the Debian Hurd
case, which has the same multiarch name reduction from i686 to i386.
i386-linux-gnu is actually Linux-only, so this moves the code of that commit
to Linux.cpp, and adds the same to Hurd.cpp
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101331
f263418402 ("[Driver] Gnu.cpp: remove obsoleted i386 triple detection
from end-of-life distribution versions") dropped the i686-gnu gcc path, but
GNU/Hurd's gcc is actually using it, and not i386.
This fixes the gcc path and update the tests to reflect it.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101317
This patch adds new clang tool named amdgpu-arch which uses
HSA to detect installed AMDGPU and report back latter's march.
This tool is built only if system has HSA installed.
The value printed by amdgpu-arch is used to fill -march when
latter is not explicitly provided in -Xopenmp-target.
Reviewed By: JonChesterfield, gregrodgers
Differential Revision: https://reviews.llvm.org/D99949
The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.
Differential Revision: https://reviews.llvm.org/D100869
This patch adds new clang tool named amdgpu-arch which uses
HSA to detect installed AMDGPU and report back latter's march.
This tool is built only if system has HSA installed.
The value printed by amdgpu-arch is used to fill -march when
latter is not explicitly provided in -Xopenmp-target.
Reviewed By: JonChesterfield, gregrodgers
Differential Revision: https://reviews.llvm.org/D99949
This patch adds new clang tool named amdgpu-arch which uses
HSA to detect installed AMDGPU and report back latter's march.
This tool is built only if system has HSA installed.
The value printed by amdgpu-arch is used to fill -march when
latter is not explicitly provided in -Xopenmp-target.
Reviewed By: JonChesterfield, gregrodgers
Differential Revision: https://reviews.llvm.org/D99949
Most text processing commands (eg. grep, awk) have a maximum line length limit on z/OS. The current method of using cc -E & grep fails on z/OS because of this limit. I'm changing the command to create the long line in the response file to use python. This avoids the possibility of any tools blocking the generation of the large response file. This also eliminates the need for the extra file.
Reviewed By: abhina.sreeskantharajan
Differential Revision: https://reviews.llvm.org/D100197
Take gcc-8 on Debian i386 as an example. The target-specific libstdc++ search
path (`GPLUSPLUS_TOOL_INCLUDE_DIR`) uses the multiarch name `i386-linux-gnu`,
instead of the triple of the GCC installation `i686-linux-gnu` (the directory
under `usr/lib/gcc/`):
```
/usr/include/c++/8
/usr/include/i386-linux-gnu/c++/8
/usr/include/c++/8/backward
```
Clang currently detects `/usr/lib/gcc/i686-linux-gnu/8/../../../include/i686-linux-gnu/c++/8`.
This patch changes the second i686-linux-gnu to i386-linux-gnu so that
`/usr/include/i386-linux-gnu/c++/8` can be found.
Fix PR49827 - this was somehow regressed by my previous libstdc++ include path
cleanups and fixes for gcc-cross, but it seems that the paths were never properly tested before.
Differential Revision: https://reviews.llvm.org/D99852
Currently, support for the x32 ABI is handled as a multilib to the
x86_64 target only. However, full self-hosting x32 systems treating it
as a separate architecture with its own architecture triplets as well as
search paths exist as well, in Debian's x32 port and elsewhere.
This adds the missing architecture triplets and search paths so that
clang can work as a native compiler on x32, and updates the tests so
that they pass when using an x32 libdir suffix.
Additionally, we would previously also assume that objects from any
x86_64-linux-gnu GCC installation could be used to target x32. This
changes the logic so that only GCC installations that include x32
support are used when targetting x32, meaning x86_64-linux-gnux32 GCC
installations, and x86_64-linux-gnu and i686-linux-gnu GCC installations
that include x32 multilib support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D52050
This helper method is useful even outside of Gnu toolchains, so move
it to ToolChain so it can be reused in other toolchains such as Fuchsia.
Differential Revision: https://reviews.llvm.org/D88452
These contain clang driver changes for supporting HWASan on Fuchsia.
This includes hwasan multilibs and the dylib path change.
Differential Revision: https://reviews.llvm.org/D99361
Debian multiarch additionally adds /usr/include/<triplet> and somehow
Android borrowed the idea. (Note /usr/<triplet>/include is already an
include dir...). On Debian, we should just assume a GCC installation is
available and use its triple.
This patch adds a new command line option to clang which outputs the directory containing clangs runtime libraries to stdout.
The primary use case for this command line flag is for build systems using clang-cl. Build systems when using clang-cl invoke the linker, that is either link or lld-link in this case, directly instead of invoking the compiler for the linking process as is common with the other drivers. This leads to issues when runtime libraries of clang, such as sanitizers or profiling, have to be linked in as the compiler cannot communicate the link directory to the linker.
Using this flag, build systems would be capable of getting the directory containing all of clang's runtime libraries and add it to the linker path.
Differential Revision: https://reviews.llvm.org/D98868
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
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
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
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
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
`sm_35` is the minimum requirement for OpenMP offloading on NVPTX device.
Current driver test case is using `sm_20`. D97003 is going to switch the minimum
CUDA version to 9.2, which only supports `sm_30+`. This patch makes step for the
change.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D97120
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
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
Generate outline atomics if compiling for armv8-a non-LSE AArch64 Linux
(including Android) targets to use LSE instructions, if they are available,
at runtime. Library support is checked by clang driver which doesn't enable
outline atomics if no proper libraries (libgcc >= 9.3.1 or compiler-rt) found.
Differential Revision: https://reviews.llvm.org/D93585
From this patch (plus some landed patches), `deviceRTLs` is taken as a regular OpenMP program with just `declare target` regions. In this way, ideally, `deviceRTLs` can be written in OpenMP directly. No CUDA, no HIP anymore. (Well, AMD is still working on getting it work. For now AMDGCN still uses original way to compile) However, some target specific functions are still required, but they're no longer written in target specific language. For example, CUDA parts have all refined by replacing CUDA intrinsic and builtins with LLVM/Clang/NVVM intrinsics.
Here're a list of changes in this patch.
1. For NVPTX, `DEVICE` is defined empty in order to make the common parts still work with AMDGCN. Later once AMDGCN is also available, we will completely remove `DEVICE` or probably some other macros.
2. Shared variable is implemented with OpenMP allocator, which is defined in `allocator.h`. Again, this feature is not available on AMDGCN, so two macros are redefined properly.
3. CUDA header `cuda.h` is dropped in the source code. In order to deal with code difference in various CUDA versions, we build one bitcode library for each supported CUDA version. For each CUDA version, the highest PTX version it supports will be used, just as what we currently use for CUDA compilation.
4. Correspondingly, compiler driver is also updated to support CUDA version encoded in the name of bitcode library. Now the bitcode library for NVPTX is named as `libomptarget-nvptx-cuda_[cuda_version]-sm_[sm_number].bc`, such as `libomptarget-nvptx-cuda_80-sm_20.bc`.
With this change, there are also multiple features to be expected in the near future:
1. CUDA will be completely dropped when compiling OpenMP. By the time, we also build bitcode libraries for all supported SM, multiplied by all supported CUDA version.
2. Atomic operations used in `deviceRTLs` can be replaced by `omp atomic` if OpenMP 5.1 feature is fully supported. For now, the IR generated is totally wrong.
3. Target specific parts will be wrapped into `declare variant` with `isa` selector if it can work properly. No target specific macro is needed anymore.
4. (Maybe more...)
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D94745
We're choosing to take an opt-in approach for landing Relative VTables, so we'll
need asan-equivalent multilibs with relative vtables enabled. Afterwards, we can
just flip the switch in our build.
Differential Revision: https://reviews.llvm.org/D95253
D94700 removed the static library so we no longer need to pass
`-llibomptarget-nvptx` to `nvlink`. Since the bitcode library is the only device
runtime for now, instead of emitting a warning when it is not found, an error
should be raised. We also set a new option `libomptarget-nvptx-bc-path` to let
user choose which bitcode library is being used.
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D95161
- Need trimming before parsing major or minor version numbers. This's required
due to the different line ending on Windows.
- In addition, the integer conversion may fail due to invalid char. Return that
parsing function return `true` when the parsing fails.
Differential Revision: https://reviews.llvm.org/D93587
Optimize toolchain regression test for VE by removing not a useful test
(-fuse-init-array test) and merge several tests to one test which checks
default behavior of driver. Also add sysroot to reduce conflicts.
These are suggested in https://reviews.llvm.org/D92996.
Thank you so much.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D93084
Leonard Chan