Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.
An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.
This adds support for:
* `muslabin32` (MIPS N32)
* `muslabi64` (MIPS N64)
* `muslf32` (LoongArch ILP32F/LP64F)
* `muslsf` (LoongArch ILP32S/LP64S)
As we start adding glibc/musl cross-compilation support for these
targets in Zig, it would make our life easier if LLVM recognized these
triples. I'm hoping this'll be uncontroversial since the same has
already been done for `musleabi`, `musleabihf`, and `muslx32`.
I intentionally left out a musl equivalent of `gnuf64` (LoongArch
ILP32D/LP64D); my understanding is that Loongson ultimately settled on
simply `gnu` for this much more common case, so there doesn't *seem* to
be a particularly compelling reason to add a `muslf64` that's basically
deprecated on arrival.
Note: I don't have commit access.
Sometimes a collection of multilibs has a gap in it, where a set of
driver command-line options can't work with any of the available
libraries.
For example, the Arm MVE extension requires special startup code (you
need to initialize FPSCR.LTPSIZE), and also benefits greatly from
-mfloat-abi=hard. So a multilib provider might build a library for
systems without MVE, and another for MVE with -mfloat-abi=hard,
anticipating that that's what most MVE users would want. But then if a
user compiles for MVE _without_ -mfloat-abi=hard, thhey can't use either
of those libraries – one has an ABI mismatch, and the other will fail to
set up LTPSIZE.
In that situation, it's useful to include a multilib.yaml entry for the
unworkable intermediate situation, and have it map to a fatal error
message rather than a set of actual libraries. Then the user gets a
build failure with a sensible explanation, instead of selecting an
unworkable library and silently generating bad output. The new
regression test demonstrates this case.
This patch introduces extra syntax into multilib.yaml, so that a record
in the `Variants` list can omit the `Dir` key, and in its place, provide
a `FatalError` key. Then, if that variant is selected, the error message
is emitted as a clang diagnostic, and multilib selection fails.
In order to emit the error message in `MultilibSet::select`, I had to
pass a `Driver &` to that function, which involved plumbing one through
to every call site, and in the unit tests, constructing one specially.
`clang` currently fails to find a GCC installation on Linux/sparc64 with
`-m32`. `strace` reveals that `clang` tries to access
`/usr/lib/gcc/sparcv9-linux-gnu` (which doesn't exist) instead of
`/usr/lib/gcc/sparc64-linux-gnu`.
It turns out that 20d497c26fc95c80a1bacb38820d92e5f52bec58 was overeager
in removing some of the necessary directories.
Fixed by reverting the Linux/sparc* part of the patch.
Tested on `sparc64-unknown-linux-gnu`.
Recommit 435ea21c897f94b5a3777a9f152e4c5bb4a371a3.
As the comment added by a07727199db0525e9d2df41e466a2a1611b3c8e1
suggests, these `*Triples` lists should shrink over time.
https://reviews.llvm.org/D158183 allows *-unknown-linux-gnu to detect
*-linux-gnu. If we additionally allow x86_64-unknown-linux-gnu
-m32/-mx32 to detect x86_64-linux-gnu, we can mostly remove these
*-linux-gnu elements.
Retain x86_64-linux-gnu for now to work around #93609.
(In addition, Debian /usr/bin/clang --version uses x86_64-pc-linux-gnu).
Retain i586-linux-gnu for now to work around #93502.
As the comment added by a07727199db0525e9d2df41e466a2a1611b3c8e1
suggests, these `*Triples` lists should shrink over time.
https://reviews.llvm.org/D158183 allows *-unknown-linux-gnu to detect
*-linux-gnu. If we additionally allow x86_64-unknown-linux-gnu
-m32/-mx32 to detect x86_64-linux-gnu, we can mostly remove these
*-linux-gnu elements.
This introduces a new file, RISCVISAUtils.cpp and moves the rest of
RISCVISAInfo to the TargetParser library.
This will allow us to generate part of RISCVISAInfo.cpp using tablegen.
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
