[Driver,test] Remove --gcc-toolchain=""

This option was added so that changing CMake GCC_INSTALL_PREFIX would
not cause test failures or due to cargo culting. Setting
GCC_INSTALL_PREFIX leads to an

[Driver,test] Remove --gcc-toolchain=""

This option was added so that changing CMake GCC_INSTALL_PREFIX would
not cause test failures or due to cargo culting. Setting
GCC_INSTALL_PREFIX leads to an error now and we should stop making our
tests ugly.

show more ...

[driver] Conditionally include installed libc++ headers for Android

https://reviews.llvm.org/D71154 prevented Clang from search for libc++
headers installed alongside the driver when targeting Andro

[driver] Conditionally include installed libc++ headers for Android

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

show more ...

[Clang][Driver] Handle LoongArch multiarch tuples

This follows v1.00 of the [[ https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html | LoongArch Toolchain Conven

[Clang][Driver] Handle LoongArch multiarch tuples

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

show more ...

Revert "[Driver][test] Replace ^//$ with empty string"

This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f.

It caused some `^/\n` and had some objection about its readability improvement.

[Driver][test] Replace ^//$ with empty string

The convention does not add //\n. Having all RUN/CHECK lines separated by //\n
makes editor movement difficult (e.g. { } in Vim).

[Clang][Driver] Fix include paths for `--sysroot /` on Linux

Currently if `--sysroot /` is passed to the Clang driver, the include paths generated by the Clang driver will start with a double slash:

[Clang][Driver] Fix include paths for `--sysroot /` on Linux

Currently if `--sysroot /` is passed to the Clang driver, the include paths generated by the Clang driver will start with a double slash: `//usr/include/...`.
If VFS is used to inject files into the include paths (for example, the Swift compiler does this), VFS will get confused and the injected files won't be visible.

This change makes sure that the include paths start with a single slash.

Fixes #28283.

Differential Revision: https://reviews.llvm.org/D126289

show more ...

[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target=

Similar to D119309

[libc++] Support per-target __config_site in per-target runtime build

When using the per-target runtime build, it may be desirable to have
different __config_site headers for each target where all t

[libc++] Support per-target __config_site in per-target runtime build

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

show more ...

[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl

This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR
should not conflict with the resource

[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl

This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR
should not conflict with the resource directory include so users should not
observe any difference.

show more ...

[test] Delete obsoleted debian_multiarch_tree and ubuntu_13.04_multiarch_tree

They are quite outdated. Delete them to avoid unnecessary test churn.

[Driver] Linux.cpp: add -internal-isystem lib/../$triple/include

With this change, for `#include <ar.h>`, `clang --target=aarch64-linux-gnu`
will read `/usr/lib/gcc/aarch64-linux-gnu/10/../../../../

[Driver] Linux.cpp: add -internal-isystem lib/../$triple/include

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.

show more ...

Revert "Revert "[Driver] Drop obsoleted Ubuntu 11.04 gcc detection""

This reverts commit 243333ef3ec6c1e3910eb442177c2e2e927e6a87.

Revert "[Driver] Drop obsoleted Ubuntu 11.04 gcc detection"

This reverts commit bdf39e6b0ed4b41a1842ac0193f30a726f8d9f63.

The change is failing on Fedora 33 (x86-64).

[Driver] Drop obsoleted Ubuntu 11.04 gcc detection

It has a very broken gcc installation path (usr/lib/i386-linux-gnu/gcc/i686-linux-gnu).

[PowerPC] Support powerpcle target in Clang [3/5]

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, whic

[PowerPC] Support powerpcle target in Clang [3/5]

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

show more ...

[Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

This fixes the Builtins-sparc-linux testsuite failures on Linux
SPARC which occur because clang cannot find the 32-bit runtime
libra

[Driver] Enable getOSLibDir() lib32 workaround for SPARC on Linux

This fixes the Builtins-sparc-linux testsuite failures on Linux
SPARC which occur because clang cannot find the 32-bit runtime
libraries when -m32 is passed on the command line. The same
workaround is already being used on X86 and PPC.

Also, switch the CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree
as both sparc and sparc64 are using the MultiArch mechanism on modern Debian
systems the same way as x86_64, powerpc64el and others. Thus, switch the
CHECK-DEBIAN-SPARC32 and CHECK-DEBIAN-SPARC64 tests to use the files from
the debian_multiarch_tree directory for the header and linker path tests.

Finally, rename CHECK-DEBIAN-SPARC32 to CHECK-DEBIAN-SPARC to match the naming
scheme of the Debian MultiArch checks for the other Debian architectures.

Reviewed By: MaskRay, phosek

Differential Revision: https://reviews.llvm.org/D90524

show more ...

[Driver] Support g++ headers in include/g++

ray's gcc installation puts C++ headers in PREFIX/include/g++ without
indicating a gcc version at all. Typically this is because the version
is encoded so

[Driver] Support g++ headers in include/g++

ray's gcc installation puts C++ headers in PREFIX/include/g++ without
indicating a gcc version at all. Typically this is because the version
is encoded somewhere in PREFIX.

Differential Revision: https://reviews.llvm.org/D53770

llvm-svn: 346802

show more ...

Fix clash of gcc toolchains in driver regression tests

For some regression tests the path to the right toolchain is specified
using the -sysroot switch. However, if clang was configured with a
custo

Fix clash of gcc toolchains in driver regression tests

For some regression tests the path to the right toolchain is specified
using the -sysroot switch. However, if clang was configured with a
custom gcc toolchain (either by using GCC_INSTALL_PREFIX in cmake or the
equivalent configure command), the path to the custom gcc toolchain path
takes precedence to the one specified by sysroot. This causes several
regression tests to fail as they will be using an unexpected path. This
patch fixes this issue by adding --gcc-toolchain='' to all tests that
rely on that. The empty string causes the driver to pick the path from
sysroot instead.

This patch contain the same kind of fixes as done in rC225182

llvm-svn: 339112

show more ...

Fix linux-header-search.cpp with CLANG_DEFAULT_CXX_STDLIB

This configuration was broken after r338294 because Clang might
be configured to always use libc++.

llvm-svn: 338360

[OpenEmbedded] Fix lib paths for OpenEmbedded targets

Summary:
The lib paths are not correctly picked up for OpenEmbedded sysroots (like arm-oe-linux-gnueabi) for 2 reasons:

1. OpenEmbedded sysroot

[OpenEmbedded] Fix lib paths for OpenEmbedded targets

Summary:
The lib paths are not correctly picked up for OpenEmbedded sysroots (like arm-oe-linux-gnueabi) for 2 reasons:

1. OpenEmbedded sysroots are of the form <sysroot>/usr/lib/<triple>/x.y.z. This form is handled in clang but only for Freescale vendor.

2. 64-bit OpenEmbedded sysroots may not have a /usr/lib dir. So they cannot find /usr/lib64 as it is referenced as /usr/lib/../lib64 in clang.

This is a follow-up to the llvm patch: D48861

Reviewers: dlj, rengolin, fedor.sergeev, javed.absar, hfinkel, rsmith

Reviewed By: rsmith

Subscribers: rsmith, kristof.beyls, cfe-commits

Differential Revision: https://reviews.llvm.org/D48862

llvm-svn: 338294

show more ...

Support for multiarch runtimes layout

This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:

lib/clang/$version/lib/$

Support for multiarch runtimes layout

This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:

lib/clang/$version/lib/$os

Clang now allows runtimes to be installed to:

lib/clang/$version/$target/lib

This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.

The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.

Differential Revision: https://reviews.llvm.org/D45604

llvm-svn: 335809

show more ...

[Driver] Update GCC libraries detection logic for Gentoo.

Summary:
1. Find GCC's LDPATH from the actual GCC config file.
2. Avoid picking libraries from a similar named tuple if the exact
tuple i

[Driver] Update GCC libraries detection logic for Gentoo.

Summary:
1. Find GCC's LDPATH from the actual GCC config file.
2. Avoid picking libraries from a similar named tuple if the exact
tuple is installed.

Reviewers: mgorny, chandlerc, thakis, rnk

Reviewed By: mgorny, rnk

Subscribers: cfe-commits, mgorny

Differential Revision: https://reviews.llvm.org/D45233

llvm-svn: 329512

show more ...

[Driver] Fix finding multilib gcc install on Gentoo (with gcc-config)

Fix the gcc-config code to support multilib gcc installs properly. This
solves two problems: -mx32 using the 64-bit gcc director

[Driver] Fix finding multilib gcc install on Gentoo (with gcc-config)

Fix the gcc-config code to support multilib gcc installs properly. This
solves two problems: -mx32 using the 64-bit gcc directory (due to matching
installation triple), and -m32 not respecting gcc-config at all (due to
mismatched installation triple).

In order to fix the former issue, split the multilib scan out of
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple() (the code
is otherwise unchanged), and call it for each installation found via
gcc-config.

In order to fix the latter issue, split the gcc-config processing out of
Generic_GCC::GCCInstallationDetector::init() and repeat it for all
triples, including extra and biarch triples. The only change
in the gcc-config code itself is adding the call to multilib scan.

Convert the gentoo_linux_gcc_multi_version_tree test input to multilib
x86_64+32+x32 install, and add appropriate tests to linux-header-search
and linux-ld.

Differential Revision: https://reviews.llvm.org/D26887

llvm-svn: 289436

show more ...

[Driver] Support obtaining active toolchain from gcc-config on Gentoo

Support using gcc-config to determine the correct GCC toolchain location
on Gentoo. In order to do that, attempt to read gcc-con

[Driver] Support obtaining active toolchain from gcc-config on Gentoo

Support using gcc-config to determine the correct GCC toolchain location
on Gentoo. In order to do that, attempt to read gcc-config configuration
form [[sysroot]]/etc/env.d/gcc, if no custom toolchain location is
provided.

Differential Revision: https://reviews.llvm.org/D25661

llvm-svn: 285074

show more ...

Teach header search about GCC 4.9 header search paths in Gentoo, they
now use the full GCC version in their weird suffix.

llvm-svn: 268874