BSD, Linux, and z/OS enable `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` by
default.
When a compiler-rt library is not found, we currently report an
incorrect filename `libclang_rt.XXX-$arch.a`
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/linux/libclang_rt.asan-x86_64.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
With this change, we will correctly report:
```
% /tmp/Debug/bin/clang++ a.cc -fsanitize=address -o a
ld.lld: error: cannot open /tmp/Debug/lib/clang/19/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a: No such file or directory
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
```
Link: https://discourse.llvm.org/t/runtime-directory-fallback/76860
`-fgpu-rdc` mode allows device functions call device functions in
different TU. However, currently all device objects have to be linked
together since only one fat binary is supported. This is time consuming
for AMDGPU backend since it only supports LTO.
There are use cases that objects can be divided into groups in which
device functions are self-contained but host functions are not. It is
desirable to link/optimize/codegen the device code and generate a fatbin
for each group, whereas partially link the host code with `ld -r` or
generate a static library by using the `--emit-static-lib` option of
clang. This avoids linking all device code together, therefore decreases
the linking time for `-fgpu-rdc`.
Previously, clang emits an external symbol `__hip_fatbin` for all
objects for `-fgpu-rdc`. With this patch, clang emits an unique external
symbol `__hip_fatbin_{cuid}` for the fat binary for each object. When a
group of objects are linked together to generate a fatbin, the symbols
are merged by alias and point to the same fat binary. Each group has its
own fat binary. One executable or shared library can have multiple fat
binaries. Device linking is done for undefined fab binary symbols only
to avoid repeated linking. `__hip_gpubin_handle` is also uniquefied and
merged to avoid repeated registering. Symbol `__hip_cuid_{cuid}` is
introduced to facilitate debugging and tooling.
Fixes: https://github.com/llvm/llvm-project/issues/77018
Introduce Code Object V6 in Clang, LLD, Flang and LLVM. This is the same
as V5 except a new "generic version" flag can be present in EFLAGS. This
is related to new generic targets that'll be added in a follow-up patch.
It's also likely V6 will have new changes (possibly new metadata
entries) added later.
Docs change are part of the follow-up patch #76955
Summary:
We support `--target=nvptx64-nvidia-cuda` as a way to target the NVPTX
architecture from standard CPU. This patch simply uses the existing
support for handling `--offload-arch=native` to also apply to the
standalone toolchain.
-fandroid-pad-segment is an Android-specific opt-in option that
links in crt_pad_segment.o (beside other crt*.o relocatable files).
crt_pad_segment.o contains a note section, which will be included in the
linker-created PT_NOTE segment. This PT_NOTE tell Bionic that: when
create a map for a PT_LOAD segment, extend the end to cover the gap so
that we will have fewer kernel 'struct vm_area_struct' objects when
page_size < MAXPAGESIZE.
See also https://sourceware.org/bugzilla/show_bug.cgi?id=31076
Link: https://r.android.com/2902180
This adds Hurd toolchain support to Clang's driver in addition to
handling
translating the triple from GCC toolchain-compatible form (x86_64-gnu)
to
the actual triple registered in LLVM (x86_64-pc-hurd-gnu).
When --gcc-triple is used, the driver will search for the 'best' gcc
installation that has the given triple. This is useful for distributions
that want clang to use a specific gcc triple, but do not want to pin to
a specific version as would be required by using --gcc-install-dir.
Having clang linked to a specific gcc version can cause clang to stop
working when the version of gcc installed on the system gets updated.
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
Add rpath for libc++ libraries in order to not specify rpath by user
each time. Disable -frthlib-add-ppath by default for VE similar to other
architectures. Update regression tests to check modifications.
Including select builtin headers in system modules is a workaround for module cycles, primarily in Apple's Darwin module that includes all of its C standard library headers. The workaround is problematic because it doesn't include all of the builtin headers (inttypes.h is notably absent), and it also doesn't include C++ headers. The straightforward for for this is to make top level modules for all of the C standard library headers and unwind.h in C++, clang, and the OS.
However, doing so in clang before the OS modules are ready re-introduces the module cycles. Add a -fbuiltin-headers-in-system-modules option to control if the special builtin headers belong to system modules or builtin modules. Pass the option by default for Apple.
Reviewed By: ChuanqiXu, Bigcheese, benlangmuir
Differential Revision: https://reviews.llvm.org/D159483
Instead of passing everything off to GCC, add a ToolChain for Haiku to allow Clang to properly link things on its own.
Co-authored-by: X512 <danger_mail@list.ru>
Co-authored-by: David Karoly <david.karoly@outlook.com>
Android triples include a version number, which makes direct triple
comparisons for per-target runtime directory searching not always work.
Instead, look for the triple with the highest compatible version number
and use that per-target runtime directory instead. This maintains the
existing fallback to a triple without any version number, but I'm hoping
we can remove that in the future. https://discourse.llvm.org/t/62717
discusses this further.
The one remaining triple mismatch after this is that Android armv7
triples usually have an environment of `androideabi`, which Clang
normalizes to `android`. If you use the `androideabi` triple when
building the runtimes with a per-target runtimes dir, the directory will
get created with `androideabi` in its name, but Clang's triple search
uses the normalized triple and will look for an `android` directory
instead. https://reviews.llvm.org/D140925 will fix that by normalizing
triples when creating the per-target runtimes directories as well.
Reviewed By: phosek, pirama
Differential Revision: https://reviews.llvm.org/D158476
Searching for target-specific standard library header and library paths
should perform fallback searches for targets, the same way searching for
the runtime libraries does. It's important for the header and library
searches to be consistent, otherwise we could end up using mismatched
headers and libraries. (See also https://reviews.llvm.org/D146664.)
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D159293
Some fixes for the header / library paths..
- Use concat macro for all paths
- Correct the C++ header paths
- Add library paths
Differential Revision: https://reviews.llvm.org/D159414
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
`clang` currently lacks PIE support on Solaris. This patch fixes this,
also linking with `crtbeginS.o` and `crtendS.o` for `-pie` and `-shared`.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D158206
Some downstream clang is configured to add -rpath to HIP runtime for ld.
Also clang may use code object version by default.
Make this test result not affected by those.
Reviewed by: Joseph Huber
Differential Revision: https://reviews.llvm.org/D157243
Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC. Before that, it
used `32` instead from a local patch.
Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.
The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.
Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D157013
This patch fixes failing tests after checking the return code from the
driver. This is mostly due to the ROCm libraries not being present
during most compilations. Passing `-nogpuinc` should allow us to compile
without it for tests that require it. Additionally, some old tests set
the architecture of Nvidia tests to `sm_35` which is officially
unsupported in CUDA 12+ so it prints an error. We just increase in this
case.
Reviewed By: MaskRay, yaxunl
Differential Revision: https://reviews.llvm.org/D156930
Similar to fsanitize-ignorelist.c.
Otherwise there may or may not be an error, depending on whether
share/cfi_ignorelist.txt is present in the default resource directory.
Exposed by D156363
If program paths (GCC installation, --sysroot, -B, etc) don't contain
ld.lld, whether -fuse-ld=lld succeeds depends on whether a PATH
directory contains ld.lld.
> error: invalid linker name in argument '-fuse-ld=lld'
This behavior is not suitable when we adopt the new strict behavior of
-### in D156363.
For some tests, append -B%S/Inputs/lld similar to D92028.
For others, use -fuse-ld=ld so that getDefaultLinker (instead of CLANG_DEFAULT_LINKER) is used. The complexity stems from CLANG_DEFAULT_LINKER.
The test added in c5fe10f365247c3dd9416b7ec8bad73a60b5946e contains
some typos in the check lines, due to which it never actually
verified what was intended.
Fix the test by adding the required input tree and adjusting the
check lines appropriately.
Differential Revision: https://reviews.llvm.org/D151195
This follows v1.00 of the [[ https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html | LoongArch Toolchain Conventions ]],
but notably with [[ https://github.com/loongson/LoongArch-Documentation/pull/80 | this patch ]]
applied (a proper version bump to v2.00 was not done, so it is
indistinguishable from the "original" but now incompatible v1.00
otherwise).
Only `loongarch64` is implemented in `Linux::getMultiarchTriple`
because support for LA32 and ILP32* ABIs are incomplete right now.
The Debian sysroot layout is based on Han Gao's recent porting effort,
specifically the ghcr.io/rabenda/beige:loong64-v23-preview-20230330
container image.
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D142688
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
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:
f81317a54586dbcef0c14cf512a0770e8ecaab3d
72474afa27570a0a1307f3260f0187b703aa6d84
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
The orginal single folder layout produced libraries in the form:
lib/linux/<libname>-<archname>.a
That archname for Arm depended on whether you had hard or soft float.
This is sometimes shown as "arm" (soft) vs. "armhf" (hard).
If this is set in a triple we do it in the final portion, the ABI.
"gnueabi" for soft float, "gnueabihf" for hard float.
Meaning that the expected triple is:
arm-unknown-linux-gnueabihf
Not this:
armhf-unknown-linux-gnueabihf
For the per target layout I have decided to rely on the ABI portion
of the triple instead of the arch name used for the old layout
(doing that would produce the invalid triple above).
This means that building with triple:
armv8l-unknown-linux-gnueabihf
Will result in libraries in:
lib/arm-unknown-linux-gnueabihf/
And clang will now know to look for "arm" instead of "armv8l".
Meaning that we can share libraries between an armv8 and armv7 build
as we did with the previous layout. In addition to handling spelling
differences e.g. "armv8l" with an "l" on some Linux distros.
compiler-rt will autodetect that the "armhf" and/or "arm" architecture
can be built. We then replace the given triple's architecture with that.
Then if the triple's float ABI doesn't match, we change that. That new
triple is then used as the folder name.
If you select to build only the given triple, with COMPILER_RT_DEFAULT_TARGET_ONLY,
compiler-rt will not autodetect the architecture and for that I assume you
know what you're doing. In that case the library path will use the unomdified triple.
From what I can tell, this is how most large builds e.g Android and
Arm's Embedded Toolchain for llvm do things. I assume that big endian "armeb"
builds would end up doing this too.
Bare metal builds will not be using per target runtime dirs so they
remain as they were.
Depends on D139536
Reviewed By: MaskRay, phosek
Differential Revision: https://reviews.llvm.org/D140011
This change fixes an issue introduced by
https://reviews.llvm.org/D140315. A new unit test was added to validate
the search for the device libraries being placed in Clang's resource
directory; however, the test didn't take into account that certain
platforms use lib64 for 64-bit library directory.
Differential Revision: https://reviews.llvm.org/D142506
Change-Id: I9c31a4f08fbc383350d82d6aba01987a3ef63e51
`Flang :: Driver/fast_math.f90` `FAIL`s on Solaris because `crtfastmath.o`
is missing from the link line.
This patch adds it as appropriate.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D141596
- Add support for finding device libraries in new ROCm directory
structure
- Simplify and remove the handling of legacy ROCm directory structure
Change-Id: I04da3bc9da85ced4b56b0225efb6b94448b8c5a1
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D140315
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
There are three functions that try to detect the right implicit
sysroot and libgcc directory setup to use
- One which looks for mingw sysroots located in
<clangbin>/../<sysrootname>
- One which looks for a mingw-targeting gcc executables in the PATH
- One which looks in the <gccroot>/lib/gcc directory to find the
right one to use, and the right specific triple used for arch
specific directories in the gcc/libstdc++ install
These have mostly tried to look for executables named
"<arch>-w64-mingw32-gcc" or "mingw32-gcc" or subdirectories
named "<arch>-w64-mingw32" or "mingw32".
In the case of findClangRelativeSysroot, it also has looked
for directories with the name of the actual triple. This
was added in deff7536278d355977171726124f83aa4bb95419,
with the intent of looking for a directory matching exactly
the user provided literal triple - however the triple here
is the normalized one, not the one provided by the user on
the command line.
Improve and unify this logic somewhat:
- Always first look for things based on the literal triple
provided by the user.
- Secondly look for things based on the normalized triple
(which usually ends up as e.g. x86_64-w64-windows-gnu),
accessed via the Triple which is passed to the constructor
- Then look for the common triple form <arch>-w64-mingw32
The literal triple provided by the user is available via
Driver::getTargetTriple(), but computeTargetTriple() may
change e.g. the architecture of it, so we need to
reapply the effective architecture on the literal triple
spelling from Driver::getTargetTriple().
Do this consistently for all of findGcc, findClangRelativeSysroot
and findGccLibDir (while keeping the existing plain "mingw32"
cases in findGcc and findGccLibDir too).
Fedora 37 started shipping mingw sysroots targeting UCRT,
in addition to the traditional msvcrt.dll, and these use
triples in the form <arch>-w64-mingw32ucrt - see
https://fedoraproject.org/wiki/Changes/F37MingwUCRT.
Thus, in addition to the existing default tested triples,
try looking for triples in the form <arch>-w64-mingw32ucrt,
to automatically find the UCRT sysroots on Fedora 37.
By explicitly setting a specific target on the Clang command
line, the user can be more explicit with which flavour is
to be preferred.
This should fix the main issue in
https://github.com/llvm/llvm-project/issues/59001.
Differential Revision: https://reviews.llvm.org/D138692
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
As now errors in file operation are handled, check for file existence
must be done prior to check for recursion, otherwise reported errors are
misleading.
Differential Revision: https://reviews.llvm.org/D136090
Clang detects the GCC version from the libdir. However, modern
GCC versions only include the major version in the libdir
(something like lib/gcc/powerpc64le-linux-gnu/12/), not all
version components. For this reason, even though the system has
a supported libstdcxx, it will still fail the check against the
12.1.0 version requirement.
Fix this by doing the same thing we do for patch versions: Assume
that a missing minor version is larger than any specific version.
To allow this to be tested, we need to fix two additional issues:
First, the GCC toolchain directories used for testing need to
contain a crtbegin.o file to be properly detected. The existing
tests actually ended up using a 0.0.0 version, rather the intended
one. Second, we also need to satisfy the glibc version check based
on the dynamic linker. To do so, respect the --dyld-prefix argument
and add the necessary file to the test toolchain directory.
Differential Revision: https://reviews.llvm.org/D136258
Make the empty headers used by cl-pch-showincludes.cpp unique so that
filesystems that link these files together by contents will not see
different behaviour in this test, which is not testing linked files
specifically.
This was uncovered by 5ea78c4113f8 which made us stop mutating the name
of the presumed loc for the file in ContentCache, but that just surfaced
an underlying issue that the filename of multiple includes of linked
files are not separately tracked.
Differential Revision: https://reviews.llvm.org/D135373
With the initial support added, clang can compile `helloworld` C
to executable file for loongarch64. For example:
```
$ cat hello.c
int main() {
printf("Hello, world!\n");
return 0;
}
$ clang --target=loongarch64-unknown-linux-gnu --gcc-toolchain=xxx --sysroot=xxx hello.c
```
The output a.out can run within qemu or native machine. For example:
```
$ file ./a.out
./a.out: ELF 64-bit LSB pie executable, LoongArch, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-loongarch-lp64d.so.1, for GNU/Linux 5.19.0, with debug_info, not stripped
$ ./a.out
Hello, world!
```
Currently gcc toolchain and sysroot can be found here:
https://github.com/loongson/build-tools/releases/download/2022.08.11/loongarch64-clfs-5.1-cross-tools-gcc-glibc.tar.xz
Reference: https://github.com/loongson/LoongArch-Documentation
The last commit hash (main branch) is:
99016636af64d02dee05e39974d4c1e55875c45b
Note loongarch32 is not fully tested because there is no reference
gcc toolchain yet.
Differential Revision: https://reviews.llvm.org/D130255
This implements support for using libc++ headers in MSVC toolchain.
We only support libc++ headers that are part of the toolchain, and
not headers installed elsewhere on the system.
Differential Revision: https://reviews.llvm.org/D101479
