Summary:
We want to pass these GPU libraries by default if a certain offloading
toolchain is loaded for OpenMP. Previously I parsed this from the
arguments because it's only available in the compilation. This doesn't
really work for `native` and it's extra effort, so this patch just
passes in the `Compilation` as an extr argument and uses that. Tests
should be unaffected.
In the case of -mno-relax option. Otherwise, we cannot prevent
relaxation if we split compilation and linking using Clang driver.
One can consider the following use case:
clang [...] -c -o myobject.o (just compile)
clang [...] myobject.o -o myobject.elf -mno-relax (linking)
In this case, myobject.elf will be relaxed, the -mno-relax will be
silently ignored.
Fix the bug where merge-fdata unconditionally outputs boltedcollection
line, regardless of whether input files have it set.
Test Plan:
Added bolt/test/X86/merge-fdata-nobat-mode.test which fails without this
fix.
-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).
If using multiarch directories with musl, the multiarch directory still
uses *-linux-gnu triples - which may or may not be intentional, while it
is somewhat consistent at least.
However, for musl armhf targets, make sure that this also picks
arm-linux-gnueabihf, rather than arm-linux-gnueabi.
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.
Extend the multi-lib re-use selection mechanism for RISC-V.
This funciton will try to re-use multi-lib if they are compatible.
Definition of compatible:
- ABI must be the same.
- multi-lib is a subset of current arch, e.g. multi-lib=march=rv32im
is a subset of march=rv32imc.
- march that contains atomic extension can't reuse multi-lib that
doesn't has atomic, vice versa. e.g. multi-lib=march=rv32im and
march=rv32ima are not compatible, because software and hardware
atomic operation can't work together correctly.
Extend the multi-lib re-use selection mechanism for RISC-V.
This funciton will try to re-use multi-lib if they are compatible.
Definition of compatible:
- ABI must be the same.
- multi-lib is a subset of current arch, e.g. multi-lib=march=rv32im
is a subset of march=rv32imc.
- march that contains atomic extension can't reuse multi-lib that
doesn't has atomic, vice versa. e.g. multi-lib=march=rv32im and
march=rv32ima are not compatible, because software and hardware
atomic operation can't work together correctly.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
The flang driver was silently ignoring the `main()` function in
`Fortran_main.a` for entry into the Fortran program unit if an external
`main()` as supplied (e.g., via cross-language linkage with Fortran and
C/C++). This PR fixes this by making sure that the linker always pulls
in the `main()` definition from `Fortran_main.a` and consequently fails
due to multiple definitions of the same symbol if another object file
also has a definition of `main()`.
This patch uses the added --dependent-lib support to add the relevant
runtimes on MSVC targets as `/DEFAULTLIB:` sections in the object file
rather than on the link line. This should help CMake support for flang
on Windows.
Fixes#63741Fixes#68017
-no-pie[1]/-nopie is rarely used and among the rare uses almost
everwhere uses -no-pie, since GCC does not recognize -nopie.
However, OpenBSD seems to use -nopie. Therefore, make -nopie specific
to OpenBSD to prevent newer ToolChains (Solaris, SerenityOS) from cargo
culting and copying -nopie.
[1]: https://reviews.llvm.org/D35462
These options select different link modes (note: -shared -static can be
used together for musl and mingw). It makes sense to place them
together, which enables some simplification. The relevant ld options
are now consistently placed after -m, similar to GCC.
While here, suppress -Wunused-command-line-argument warning when -shared
-rdynamic are used together (introduced by commit
291f4a00232b5742940d67e2ecf9168631251317). It can be argued either way
whether the warning is justified (in ELF linkers --export-dynamic
functionality is subsumed by -shared), but it is not useful (users can
do -Wl,--export-dynamic, bypassing the driver diagnostic).
-export-dynamic is specified twice when -static is not specified. Fix
it.
While here, make some simplification, which can match GCC behavior as a
side benefit: suppress -export-dynamic for -static-pie/-shared. (GCC
passes -export-dynamic when -r is specified. This is unimportant
trivia).
This change largely has no behavior difference, since GNU ld and gold
ignore -export-dynamic when creating a statically linked executable or a
shared object.
Currently flang's runtime libraries are only built for the specific CRT
that LLVM itself was built against. This patch adds the cmake logic for
building a separate runtime for each CRT configuration and adds a flag
for selecting a CRT configuration to link against.
Previously, if a linker argument (i.e. -Wl) is presented before any input
filenames, Gnu driver would use the InputInfo object of that argument to generate stats filename for LTO backend, causing an empty filename. This patch fixes such issue.
In earlier GCC versions, the Debian/Ubuntu provided mingw toolchains
were packaged in /usr/lib/gcc/<triple> with version strings such as
"5.3-win32", which were matched and found since
6afcd64eb65fca233a7b173f88cffb2c2c9c114c. However in recent versions,
they have stopped including the minor version number and only have
version strings such as "10-win32" and "10-posix".
Generalize the parsing code to tolerate the patch suffix to be present
on a version number with only a major number.
Refactor the string parsing code to highlight the overall structure of
the parsing. This implementation should yield the same result as before,
except for when there's only one segment and it has trailing, non-number
contents.
This allows Clang to find the GCC libraries and headers in Debian/Ubuntu
provided MinGW cross compilers.
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>
b1e3cd1d79443603dc003441e07cdd8d30bb7f26 dropped the leading slash here,
presumably unintentionally.
(I don't understand Driver well enough to know how/where this is
supposed
to be tested, but it broke clangd on any project that uses the
system-installed -stdlib=libc++ on a standard debian install)
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
https://reviews.llvm.org/D71154 prevented Clang from search for libc++
headers installed alongside the driver when targeting Android. The
motivation was the NDK's use of a different libc++ inline namespace
(`__ndk1` instead of the standard `__1`), which made regular libc++
headers incompatible with the NDK's libc++ library.
Since then, libc++ has gained the ability to install its `__config_site`
header (which controls the inline namespace, among other things) to a
per-target include directory, which enables per-target customizations.
If this directory is present, the user has expressly built libc++ for
Android, and we should use those headers.
The motivation is that, with the current setup, if a user builds their
own libc++ for Android, they'll use the library they built themselves
but the NDK's headers instead of their own, which is surprising at best
and can cause all sorts of problems (e.g. if you built your own libc++
with a different ABI configuration). It's important to match the headers
and libraries in that scenario, and checking for an Android per-target
include directory lets us do so without regressing the original scenario
which https://reviews.llvm.org/D71154 was addressing.
While I'm here, switch to using sys::path::append instead of slashes
directly, to get system path separators on Windows, which is consistent
with how library paths are constructed (and that consistency will be
important in a follow-up, where we use a common search function for the
include and library path construction).
(As an aside, one of the motivations for https://reviews.llvm.org/D71154
was to support targeting both Android and Apple platforms, which
expected libc++ headers to be provided by the toolcain at the time.
Apple has since switched to including libc++ headers in the platform SDK
instead of in the toolchain, so that specific motivation no longer
applies either.)
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D159292
`clang -fno-integrated-as` doesn't currently work on Solaris: it doesn't
even select between 32 and 64-bit objects. Besides, Solaris has both the
native assembler (`/usr/bin/as`) and the GNU assembler (`/usr/bin/gas`
resp. `/usr/gnu/bin/as`). The native sparc and x86 assemblers aren't
compatible with `clang`'s assembler syntax to varying degrees, and the
command line options for `as` and `gas` are completely different.
Therefore this patch chooses to always use `gas` on Solaris, using
`gnutools::Assembler::ConstructJob` to pass the correct options.
Tested on `amd64-pc-solaris2.11`, `sparcv9-sun-solaris2.11`, and
`x86_64-pc-linux-gnu`.
While looking over the Solaris GNU ld patch (D85309
<https://reviews.llvm.org/D85309>), I noticed that we weren't using
`isOSSolaris()` consistenly in `clang`. This patch fixes this.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D159222
Following the lead of the Linux code, this patch passes the `ld -z` options
as two separate args on Solaris, improving legibility. For lack of a
variadic `std::push_back`, `getAsNeededOption` had to be changed to
`addAsNeededOption`, matching other `add*Options` functions, changing
callers accordingly. The additional args are also used in a WIP revision
of the Solaris GNU ld patch D85309 <https://reviews.llvm.org/D85309>, which
will allow runtime selection of the linker to use.
Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.
Differential Revision: https://reviews.llvm.org/D158955
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
If ScanLibDirForGCCTriple with target triple fails, let's try the triple with
vendor stripped if vendor is unknown.
Debian always uses triples without a vendor section. In general, triples without
a vendor section is the most similar aliases than any other aliases.
To archive this, we add a private member TripleNoVendor to
GCCInstallationDetector.
This modification makes testcases riscv32-toolchain.c and riscv64-toolchain.c
fail. The reason is that they are wrong: --triple riscv64-unknown-elf tries
to use riscv64-unknown-linux-gnu first.
This patch accidentally fixes this problem.
We also drop the path delimiter pattern {{/|\\\\}}, as these 2 tests are
disabled on Windows, and in fact the positions of this pattern are not
correct.
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D158183
When doing combined compilation/link for HIP source
files, clang should link the HIP runtime library
automatically without --hip-link.
Reviewed by: Siu Chi Chan, Joseph Huber
Differential Revision: https://reviews.llvm.org/D156426
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
Solaris 12 was re-christened as Solaris 11.4 while still in beta, so all
references are long obsolete and can be removed.
Tested on `amd64-pc-solaris2.11`.
Differential Revision: https://reviews.llvm.org/D156861
IsARMBIgEndian function returns true only if:
1. The triples are either arm or thumb and the
commandline has the option -mbig-endian
2. The triples are either armeb or thumbeb.
Missing the checking of arm or thumb triples in the
first case pass through the --be8 endian flag to
linker For AArch64 as well which is not expected.
This is the regression happened from the previous
patch https://reviews.llvm.org/D154786.
It is better to refactor to only call IsARMBigEndian
for isARM and isthumb satisfying conditions which
keeps ARM and AArch64 separate.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D155808
When linking a big-endian image for Arm, clang has
to select between BE8 and BE32 formats. The default
is dependent on the selected target architecture.
For ARMv6 and later architectures the default is
BE8, for older architectures the default is BE32.
For BE8 and BE32, compiler outputs a big endian ELF
relocatable object file with the instructions and
data both big endian. The difference is that at
link time, for BE8 a linker must endian reverse
the instructions to little endian. For BE8, the
clang has to pass --be8 to the linker for Arm.
At the moment clang is not passing the --be8 flag
to linker for the baremetal target architectures
above ArmV6 for Arm. This patch passes through --be8
and -BE or EL to the linker, taking into account the
target and the -mbig-endian and -mlittle-endian flag.
Also there are few more changes in the baremetal
driver so that the code can cope with AArch64 being
big-endian as well.
Reviewed By: michaelplatings, MaskRay
Differential Revision: https://reviews.llvm.org/D154786
This will enable layering multilibs on top of each other.
For example a multilib containing only a no-exceptions libc++ could be
layered on top of a multilib containing C libs. This avoids the need
to duplicate the C library for every libc++ variant.
This change doesn't expose the functionality externally, it only opens
the functionality up to be potentially used by ToolChain classes.
Differential Revision: https://reviews.llvm.org/D143059
Decouple the interface of the MultilibBuilder flag method from how flags
are stored internally. Likewise change the addMultilibFlag function.
Currently a multilib flag like "-fexceptions" means a multilib is
*incompatible* with the -fexceptions command line option, which is
counter-intuitive. This change is a step towards changing this scheme.
Differential Revision: https://reviews.llvm.org/D151437
This change is necessary to set correct EFlags according to the
options (-m*-float and -mabi=) passed to clang when input is assembly.
Note: `-mabi=` is not documented by `as`.
```
$ as --version
GNU assembler (GNU Binutils) 2.40.50.20230316
...
$ as --target-help
LARCH options:
```
But we can see gcc invokes `as` and passes the `-mabi=` option when compiling C or assembly.
```
$ gcc -c a.c -v 2>&1 -msoft-float | grep "as -v"
as -v -mabi=lp64s -o a.o /tmp/ccFrxzZi.s
$ gcc -c a.s -v 2>&1 -msoft-float | grep "as -v"
as -v -mabi=lp64s -o a.o a.s
```
Reviewed By: xen0n
Differential Revision: https://reviews.llvm.org/D150537
