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.
With this change, on Debian x86-64 (with a MULTILIB_OSDIRNAMES local patch
../lib64 -> ../lib; this does not matter because /usr/lib64/crt{1,i,n}.o do not exist),
`clang++ --target=aarch64-linux-gnu a.cc -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath,/usr/aarch64-linux-gnu/lib`
built executable can run under qemu-user. Previously this failed with
`/usr/lib/gcc-cross/aarch64-linux-gnu/10/../../../../include/c++/10/iostream:38:10: fatal error: 'bits/c++config.h' file not found`
On Arch Linux, due to the MULTILIB_OSDIRNAMES patch and the existence of
/usr/lib64/crt{1,i,n}.o, clang driver may pick
/usr/lib64/crt{1,i,n}.o and cause a linker error. -B can work around the problem.
`clang++ --target=aarch64-linux-gnu -B /usr/aarch64-linux-gnu/lib a.cc -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath,/usr/aarch64-linux-gnu/lib64:/usr/aarch64-linux-gnu/lib`
With this change, for `#include <ar.h>`, `clang --target=aarch64-linux-gnu`
will read `/usr/lib/gcc/aarch64-linux-gnu/10/../../../../aarch64-linux-gnu/include/ar.h`
(on Debian gcc->gcc-cross)
instead of `/usr/include/ar.h`. Some glibc headers (e.g. gnu/stubs.h) are different across architectures.
Seem unnecessary to diverge from GCC here.
Beside, lib/../$OSLibDir can be considered closer to the GCC
installation then the system root. The comment should not apply.
After path resolution, it duplicates a subsequent -L entry. The entry below
(lib/gcc/$triple/$version/../../../../$OSLibDir) usually does not exist (e.g.
Arch Linux; Debian cross gcc). When it exists, it typically just has ld.so (e.g.
Debian native gcc) which cannot cause collision. Removing the -L (similar to
reordering it) is therefore justified.
so that when --sysroot is specified, the detected GCC installation will not be
overridden by another from /usr which happens to have a larger version.
This behavior is particularly inconvenient when the system has a larger version
GCC while the user wants to try out an older sysroot.
Delete some tests from linux-ld.c which overlap with cross-linux.c
In GCC, if `-B $prefix` is specified, `$prefix` is used to find executable files and startup files.
`$prefix/include` is added as an include search directory.
Clang overloads -B with GCC installation detection semantics which make the
behavior less predictable (due to the "largest GCC version wins" rule) and
interact poorly with --gcc-toolchain (--gcc-toolchain can be overridden by -B).
* `clang++ foo.cpp` detects GCC installation under `/usr`.
* `clang++ --gcc-toolchain=Inputs foo.cpp` detects GCC installation under `Inputs`.
* `clang++ -BA --gcc-toolchain=B foo.cpp` detects GCC installation under A and B and the larger version wins. With this patch, only B is used for detection.
* `clang++ -BA foo.cpp` detects GCC installation under `A` and `/usr`, and the larger GCC version wins. With this patch `A` is not used for detection.
This patch changes -B to drop the GCC detection semantics. Its executable
searching semantics are preserved. --gcc-toolchain is the recommended option to
specify the GCC installation detection directory.
(
Note: Clang detects GCC installation in various target dependent directories.
`$sysroot/usr` (sysroot defaults to "") is a common directory used by most targets.
Such a directory is expected to contain something like `lib{,32,64}/gcc{,-cross}/$triple`.
Clang will then construct library/include paths from the directory.
)
Differential Revision: https://reviews.llvm.org/D97993
If --gcc-toolchain is specified, we should detect GCC installation there, and suppress other directories for detection.
Reviewed By: mgorny, manojgupta
Differential Revision: https://reviews.llvm.org/D97894
When building a 64-bit big endian PowerPC Linux kernel with a 64-bit
little endian PowerPC target, the 32-bit vDSO errors:
```
$ make ARCH=powerpc CC=clang CROSS_COMPILE=powerpc64le-linux-gnu- \
pseries_defconfig arch/powerpc/kernel/vdso32/
ld.lld: error: arch/powerpc/kernel/vdso32/sigtramp.o is incompatible with elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/gettimeofday.o is incompatible with elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/datapage.o is incompatible with elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/cacheflush.o is incompatible with elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/note.o is incompatible with elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/getcpu.o is incompatible with elf32-powerpc
ld.lld: error: arch/powerpc/kernel/vdso32/vgettimeofday.o is incompatible with elf32-powerpc
...
```
This happens because the endian information is missing from the call to
the assembler, even though it was explicitly passed to clang. See the
below example.
```
$ echo | clang --target=powerpc64le-linux-gnu \
--prefix=/usr/bin/powerpc64le-linux-gnu- \
-no-integrated-as -m32 -mbig-endian -### -x c -c -
".../clang-12" "-cc1" "-triple" "powerpc-unknown-linux-gnu" ...
...
"/usr/bin/powerpc64le-linux-gnu-as" "-a32" "-mppc" "-many" "-o" "-.o" "/tmp/--e69e28.s"
```
clang sets the right target with -m32 and -mbig-endian but -mbig-endian
does not make it to the assembler, resulting in a 32-bit little endian
binary. This differs from the little endian targets, which always pass
-mlittle-endian.
```
$ echo | clang --target=powerpc64-linux-gnu \
--prefix=/usr/bin/powerpc64-linux-gnu- \
-no-integrated-as -m32 -mlittle-endian -### -x c -c -
".../clang-12" "-cc1" "-triple" "powerpcle-unknown-linux-gnu" ...
...
"/usr/bin/powerpc64-linux-gnu-as" "-a32" "-mppc" "-mlittle-endian" "-many" "-o" "-.o" "/tmp/--405dbd.s"
```
Do the same thing for the big endian targets so that there is no more
error. This matches GCC's behavior, where -mbig and -mlittle are always
passed along to GNU as.
```
$ echo | powerpc64-linux-gcc -### -x c -c -
...
.../powerpc64-linux/bin/as -a64 -mpower4 -many -mbig -o -.o /tmp/ccVn7NAm.s
...
$ echo | powerpc64le-linux-gcc -### -x c -c -
...
.../powerpc64le-linux/bin/as -a64 -mpower8 -many -mlittle -o -.o /tmp/ccPN9ato.s
...
```
Reviewed By: nickdesaulniers, MaskRay
Differential Revision: https://reviews.llvm.org/D94442
While trying to compile clang and openmp with a freshly built clang with the gcc/7.4.0
toolchain on the Summit supercomputer I face some error because of the triple under which
the GCC toolchain is installed was not present in for PPC64LE triples.
This patch add the powerpc64le-none-linux-gnu used on system like Summit and Ascent.
Reviewed By: jdenny
Differential Revision: https://reviews.llvm.org/D94261
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
GCC made the switch on 2018-04-10 ("rs6000: Enable -fasynchronous-unwind-tables by default").
In Clang, FreeBSD/NetBSD powerpc have already defaulted to -fasynchronous-unwind-tables.
This patch defaults Generic_GCC powerpc (which affects Linux) to use -fasynchronous-unwind-tables.
Reviewed By: #powerpc, nemanjai
Differential Revision: https://reviews.llvm.org/D92054
In GCC, `aarch64-*-linux` and `aarch64-*-freebsd` made the switch in 2018
(https://gcc.gnu.org/pipermail/gcc-patches/2018-March/495549.html).
In Clang, FreeBSD/Fuchsia/NetBSD/MinGW aarch64 default to -fasynchronous-unwind-tables.
This patch defaults Generic_GCC aarch64 (which affects Linux) to use -fasynchronous-unwind-tables.
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D91760
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
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
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
Check whether /etc/env.d/gcc exists before trying to read from any
file from there. This saves a few OS calls on a non-Gentoo system.
Differential Revision: https://reviews.llvm.org/D87143
recommit e50465ecefc964e5700df26fc7e02a673eed085a 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
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
Instead of accepting the same arguments as regular linker,
the static linker will only accept input files.
Reviewed By: yaxunl
Differential Revision: https://reviews.llvm.org/D85442
Many driver options are neither 'DriverOption' nor 'LinkerInput'. When gcc is
used for linking, these options get forwarded even if they don't have anything
to do with linking. Among these options, clang-specific ones can cause gcc to
error.
Just use 'OPT_Link_Group' and a new flag 'LinkOption' for options which already
have a group.
gfortran support apparently bit rots (which does not seem to make much sense). XFAIL the test.
Do not detect device library by default in rocm detector.
Only detect device library in Rocm and HIP toolchain.
Separate detection of HIP runtime and Rocm device library.
Detect rocm path by version file in host toolchains.
Also added detecting rocm version and printing rocm
installation path and version with -v.
Fixed include path and device library detection for
ROCm 3.5.
Added --hip-version option. Renamed --hip-device-lib-path
to --rocm-device-lib-path.
Fixed default value for -fhip-new-launch-api.
Added default -std option for HIP.
Differential Revision: https://reviews.llvm.org/D82930
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
Add GNU Static Lib Tool, which supports the --emit-static-lib
flag. For HIP, a static library archive will be created and
consist of HIP Fat Binary host object with the device images embedded.
Using llvm-ar to create the static archive. Also, delete existing
output file to ensure a new archive is created each time.
Reviewers: yaxunl, tra, rjmccall, echristo
Subscribers: echristo, JonChesterfield, scchan, msearles
Differential Revision: https://reviews.llvm.org/D78759
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:
The Android NDK's clang driver is used with an Android -target setting,
and the driver automatically finds the Android sysroot at a path
relative to the driver. The sysroot has the libc++ headers in it.
Remove Hurd::computeSysRoot as it is equivalent to the new
ToolChain::computeSysRoot method.
Fixes PR46213.
Reviewers: srhines, danalbert, #libc, kristina
Reviewed By: srhines, danalbert
Subscribers: ldionne, sthibaul, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D81622
