Currently, support for the x32 ABI is handled as a multilib to the
x86_64 target only. However, full self-hosting x32 systems treating it
as a separate architecture with its own architecture triplets as well as
search paths exist as well, in Debian's x32 port and elsewhere.
This adds the missing architecture triplets and search paths so that
clang can work as a native compiler on x32, and updates the tests so
that they pass when using an x32 libdir suffix.
Additionally, we would previously also assume that objects from any
x86_64-linux-gnu GCC installation could be used to target x32. This
changes the logic so that only GCC installations that include x32
support are used when targetting x32, meaning x86_64-linux-gnux32 GCC
installations, and x86_64-linux-gnu and i686-linux-gnu GCC installations
that include x32 multilib support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D52050
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.
llvm-svn: 225182
In many Linux environments (and similar), just-built applications won't run
correctly without making use of the current LD_LIBRARY_PATH environmental
variable in order to find dynamic libraries. Propagate it through the 'env'
command (hopefully this works on all platforms).
llvm-svn: 223219
I'm explicitly setting LC_ALL=C somewhat for documentation, but
hopefully this also removes some host variation from the test results.
llvm-svn: 223102
environment variable is changed to strange things out from under it.
Prior to r223099 in LLVM, these test cases would crash in various ways
(assert fails, stack exhaustion, etc.).
llvm-svn: 223100
Petr Hosek