maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Driver/linux-header-search.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

532 lines
36 KiB
C++
Raw Normal View History

Fix an issue that Duncan discovered on a specific (no longer current) version of Ubuntu. It has a very broken multiarch configuration, and so we need special logic to handle it correctly. Fixing and testing this uncovered a few other trivial issues with the logic that are fixed as well. I added tests to cover this as it is hard to notice if you install recent versions of the OS. llvm-svn: 144165
2011-11-09 11:46:20 +08:00
// General tests that the header search paths detected by the driver and passed
// to CC1 are sane.
//
Make the Linux support for finding libc++ somewhat less braindead. Now instead of just looking in the system root for it, we also look relative to the clang binary's directory. This should "just work" in almost all cases. I've added test cases accordingly. This is probably *very* worthwhile to backport to the 3.4 branch so that folks can check it out, build it, and use that as their host compiler going forward. llvm-svn: 199632
2014-01-20 17:42:24 +08:00
// Test a simulated installation of libc++ on Linux, both through sysroot and
// the installation path of Clang.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
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
2018-06-28 11:11:52 +08:00
// RUN: -resource-dir=%S/Inputs/resource_dir \
Make the Linux support for finding libc++ somewhat less braindead. Now instead of just looking in the system root for it, we also look relative to the clang binary's directory. This should "just work" in almost all cases. I've added test cases accordingly. This is probably *very* worthwhile to backport to the 3.4 branch so that folks can check it out, build it, and use that as their host compiler going forward. llvm-svn: 199632
2014-01-20 17:42:24 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Make the Linux support for finding libc++ somewhat less braindead. Now instead of just looking in the system root for it, we also look relative to the clang binary's directory. This should "just work" in almost all cases. I've added test cases accordingly. This is probably *very* worthwhile to backport to the 3.4 branch so that folks can check it out, build it, and use that as their host compiler going forward. llvm-svn: 199632
2014-01-20 17:42:24 +08:00
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-SYSROOT %s
// CHECK-BASIC-LIBCXX-SYSROOT: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-BASIC-LIBCXX-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v1"
// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_libcxx_tree/usr/bin \
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
2018-06-28 11:11:52 +08:00
// RUN: -resource-dir=%S/Inputs/resource_dir \
Make the Linux support for finding libc++ somewhat less braindead. Now instead of just looking in the system root for it, we also look relative to the clang binary's directory. This should "just work" in almost all cases. I've added test cases accordingly. This is probably *very* worthwhile to backport to the 3.4 branch so that folks can check it out, build it, and use that as their host compiler going forward. llvm-svn: 199632
2014-01-20 17:42:24 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Make the Linux support for finding libc++ somewhat less braindead. Now instead of just looking in the system root for it, we also look relative to the clang binary's directory. This should "just work" in almost all cases. I've added test cases accordingly. This is probably *very* worthwhile to backport to the 3.4 branch so that folks can check it out, build it, and use that as their host compiler going forward. llvm-svn: 199632
2014-01-20 17:42:24 +08:00
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-INSTALL %s
// CHECK-BASIC-LIBCXX-INSTALL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-BASIC-LIBCXX-INSTALL: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-BASIC-LIBCXX-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/bin/../include/c++/v1"
// CHECK-BASIC-LIBCXX-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
//
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-10 05:10:54 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
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
2018-06-28 11:11:52 +08:00
// RUN: -resource-dir=%S/Inputs/resource_dir \
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-10 05:10:54 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-SYSROOT %s
// CHECK-BASIC-LIBCXXV2-SYSROOT: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v2"
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_libcxxv2_tree/usr/bin \
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
2018-06-28 11:11:52 +08:00
// RUN: -resource-dir=%S/Inputs/resource_dir \
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-10 05:10:54 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-INSTALL %s
// CHECK-BASIC-LIBCXXV2-INSTALL: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-BASIC-LIBCXXV2-INSTALL: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-BASIC-LIBCXXV2-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/bin/../include/c++/v2"
// CHECK-BASIC-LIBCXXV2-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
//
// Test Linux with both libc++ and libstdc++ installed.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
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
2018-06-28 11:11:52 +08:00
// RUN: -resource-dir=%S/Inputs/resource_dir \
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-10 05:10:54 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_libstdcxx_libcxxv2_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT %s
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v2"
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
//
Fix an issue that Duncan discovered on a specific (no longer current) version of Ubuntu. It has a very broken multiarch configuration, and so we need special logic to handle it correctly. Fixing and testing this uncovered a few other trivial issues with the logic that are fixed as well. I added tests to cover this as it is hard to notice if you install recent versions of the OS. llvm-svn: 144165
2011-11-09 11:46:20 +08:00
// Test a very broken version of multiarch that shipped in Ubuntu 11.04.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target i386-unknown-linux -stdlib=libstdc++ \
Fix an issue that Duncan discovered on a specific (no longer current) version of Ubuntu. It has a very broken multiarch configuration, and so we need special logic to handle it correctly. Fixing and testing this uncovered a few other trivial issues with the logic that are fixed as well. I added tests to cover this as it is hard to notice if you install recent versions of the OS. llvm-svn: 144165
2011-11-09 11:46:20 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_11.04_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Fix an issue that Duncan discovered on a specific (no longer current) version of Ubuntu. It has a very broken multiarch configuration, and so we need special logic to handle it correctly. Fixing and testing this uncovered a few other trivial issues with the logic that are fixed as well. I added tests to cover this as it is hard to notice if you install recent versions of the OS. llvm-svn: 144165
2011-11-09 11:46:20 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-11-04 %s
// CHECK-UBUNTU-11-04: "{{.*}}clang{{.*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-11-04: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Fix an issue that Duncan discovered on a specific (no longer current) version of Ubuntu. It has a very broken multiarch configuration, and so we need special logic to handle it correctly. Fixing and testing this uncovered a few other trivial issues with the logic that are fixed as well. I added tests to cover this as it is hard to notice if you install recent versions of the OS. llvm-svn: 144165
2011-11-09 11:46:20 +08:00
// CHECK-UBUNTU-11-04: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-11-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5"
// CHECK-UBUNTU-11-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5/i686-linux-gnu"
// CHECK-UBUNTU-11-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5/backward"
// CHECK-UBUNTU-11-04: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-11-04: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
Fix an issue that Duncan discovered on a specific (no longer current) version of Ubuntu. It has a very broken multiarch configuration, and so we need special logic to handle it correctly. Fixing and testing this uncovered a few other trivial issues with the logic that are fixed as well. I added tests to cover this as it is hard to notice if you install recent versions of the OS. llvm-svn: 144165
2011-11-09 11:46:20 +08:00
// CHECK-UBUNTU-11-04: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-UBUNTU-11-04: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
//
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_13.04_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-13-04 %s
// CHECK-UBUNTU-13-04: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-13-04: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// CHECK-UBUNTU-13-04: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-13-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7"
// CHECK-UBUNTU-13-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7"
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// CHECK-UBUNTU-13-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/backward"
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// CHECK-UBUNTU-13-04: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-13-04: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// CHECK-UBUNTU-13-04: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/x86_64-linux-gnu"
// CHECK-UBUNTU-13-04: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-UBUNTU-13-04: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
Fix gcc search for cross-compiler on Ubuntu 13.04. Just more craziness to find crtbegin.o etc. Patch by Stephen Kelly. llvm-svn: 187175
2013-07-26 08:53:40 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-unknown-linux-gnux32 -stdlib=libstdc++ \
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-14-04 %s
// CHECK-UBUNTU-14-04: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-14-04: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
// CHECK-UBUNTU-14-04: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-14-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8"
// CHECK-UBUNTU-14-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8/x32"
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// CHECK-UBUNTU-14-04: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward"
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
// CHECK-UBUNTU-14-04: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-14-04: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[x32] Adding X32 target support to driver, including TargetInfo,DescriptionString, flags, paths lookup, etc. Cover changes with new tests. The author of the patch is Pavel Chupin (@pavel.v.chupin). The changes enable "hello world" on x32 target (x86_64-*-linux-gnux32). s/isX32/IsX32/ also fixed. Differential Revision: http://reviews.llvm.org/D4180 llvm-svn: 212725
2014-07-10 23:27:19 +08:00
// CHECK-UBUNTU-14-04: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/x86_64-linux-gnu"
// CHECK-UBUNTU-14-04: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-UBUNTU-14-04: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
///
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target arm-linux-gnueabihf -stdlib=libstdc++ \
Fix gcc search for cross-compiler on Ubuntu 13.04. Just more craziness to find crtbegin.o etc. Patch by Stephen Kelly. llvm-svn: 187175
2013-07-26 08:53:40 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_13.04_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Fix gcc search for cross-compiler on Ubuntu 13.04. Just more craziness to find crtbegin.o etc. Patch by Stephen Kelly. llvm-svn: 187175
2013-07-26 08:53:40 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-13-04-CROSS %s
// CHECK-UBUNTU-13-04-CROSS: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-13-04-CROSS: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Fix gcc search for cross-compiler on Ubuntu 13.04. Just more craziness to find crtbegin.o etc. Patch by Stephen Kelly. llvm-svn: 187175
2013-07-26 08:53:40 +08:00
// CHECK-UBUNTU-13-04-CROSS: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-13-04-CROSS: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabihf/4.7/../../../../include/c++/4.7"
// CHECK-UBUNTU-13-04-CROSS: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabihf/4.7/../../../../include/arm-linux-gnueabihf/c++/4.7"
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// CHECK-UBUNTU-13-04-CROSS: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabihf/4.7/../../../../include/c++/4.7/backward"
Fix gcc search for cross-compiler on Ubuntu 13.04. Just more craziness to find crtbegin.o etc. Patch by Stephen Kelly. llvm-svn: 187175
2013-07-26 08:53:40 +08:00
// CHECK-UBUNTU-13-04-CROSS: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-UBUNTU-13-04-CROSS: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
Fix gcc search for cross-compiler on Ubuntu 13.04. Just more craziness to find crtbegin.o etc. Patch by Stephen Kelly. llvm-svn: 187175
2013-07-26 08:53:40 +08:00
// CHECK-UBUNTU-13-04-CROSS: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-UBUNTU-13-04-CROSS: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// Test Ubuntu/Debian's new version of multiarch, with -m32.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-unknown-linux-gnu -m32 -stdlib=libstdc++ \
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_13.04_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-13-04-M32 %s
// CHECK-UBUNTU-13-04-M32: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-UBUNTU-13-04-M32: "-triple" "i386-unknown-linux-gnu"
// CHECK-UBUNTU-13-04-M32: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-13-04-M32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7"
// CHECK-UBUNTU-13-04-M32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/x86_64-linux-gnu/c++/4.7/32"
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// CHECK-UBUNTU-13-04-M32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/backward"
Driver: add support for new style multiarch in Ubuntu 13.04 Patch by Sanne Wouda. llvm-svn: 176557
2013-03-07 01:14:05 +08:00
//
[Driver] Do not lose already detected set of toolchain's multilibs while iterating over different library path suffixes and different library versions. To find the most appropriate library for the given command line flags we iterate over a set of disk paths. Before probe each path the already detected set of multilibs are cleared. If the set of paths contains existing paths which do not satisfy command line flags or do not contain necessary libraries and object files at all we might lose found multilibs. The patch updates variables which hold detected multilibs if we really find a new multilib matches command line flags. The patch reviewed by Jon Roelofs. llvm-svn: 208523
2014-05-12 15:37:51 +08:00
// Test Ubuntu/Debian's Ubuntu 14.04 config variant, with -m32
// and an empty 4.9 directory.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-unknown-linux-gnu -m32 -stdlib=libstdc++ \
[Driver] Do not lose already detected set of toolchain's multilibs while iterating over different library path suffixes and different library versions. To find the most appropriate library for the given command line flags we iterate over a set of disk paths. Before probe each path the already detected set of multilibs are cleared. If the set of paths contains existing paths which do not satisfy command line flags or do not contain necessary libraries and object files at all we might lose found multilibs. The patch updates variables which hold detected multilibs if we really find a new multilib matches command line flags. The patch reviewed by Jon Roelofs. llvm-svn: 208523
2014-05-12 15:37:51 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
[Driver] Do not lose already detected set of toolchain's multilibs while iterating over different library path suffixes and different library versions. To find the most appropriate library for the given command line flags we iterate over a set of disk paths. Before probe each path the already detected set of multilibs are cleared. If the set of paths contains existing paths which do not satisfy command line flags or do not contain necessary libraries and object files at all we might lose found multilibs. The patch updates variables which hold detected multilibs if we really find a new multilib matches command line flags. The patch reviewed by Jon Roelofs. llvm-svn: 208523
2014-05-12 15:37:51 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-14-04-M32 %s
// CHECK-UBUNTU-14-04-M32: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-UBUNTU-14-04-M32: "-triple" "i386-unknown-linux-gnu"
// CHECK-UBUNTU-14-04-M32: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-14-04-M32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8"
// CHECK-UBUNTU-14-04-M32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8/32"
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// CHECK-UBUNTU-14-04-M32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward"
//
// Test Ubuntu/Debian's Ubuntu 14.04 with -m32 and an i686 cross compiler
// installed rather than relying on multilib. Also happens to look like an
// actual i686 Ubuntu system.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-unknown-linux-gnu -m32 -stdlib=libstdc++ \
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree2 \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-14-04-I686 %s
// CHECK-UBUNTU-14-04-I686: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-UBUNTU-14-04-I686: "-triple" "i386-unknown-linux-gnu"
// CHECK-UBUNTU-14-04-I686: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-14-04-I686: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.8/../../../../include/c++/4.8"
// CHECK-UBUNTU-14-04-I686: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.8/../../../../include/i386-linux-gnu/c++/4.8"
// CHECK-UBUNTU-14-04-I686: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.8/../../../../include/c++/4.8/backward"
[Driver] Do not lose already detected set of toolchain's multilibs while iterating over different library path suffixes and different library versions. To find the most appropriate library for the given command line flags we iterate over a set of disk paths. Before probe each path the already detected set of multilibs are cleared. If the set of paths contains existing paths which do not satisfy command line flags or do not contain necessary libraries and object files at all we might lose found multilibs. The patch updates variables which hold detected multilibs if we really find a new multilib matches command line flags. The patch reviewed by Jon Roelofs. llvm-svn: 208523
2014-05-12 15:37:51 +08:00
//
[PowerPC] Add MultiarchIncludeDirs for powerpc64le There was already partial support for multi-arch on powerpc64le, but the MultiarchIncludeDirs setting was missing. This patch adds the appropriate definition, and also extends the linux-header-search.cpp test case to verify an Ubuntu 14.04 powerpc64le tree. llvm-svn: 211359
2014-06-20 21:41:24 +08:00
// Test Ubuntu/Debian's Ubuntu 14.04 for powerpc64le
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target powerpc64le-unknown-linux-gnu -m32 -stdlib=libstdc++ \
[PowerPC] Add MultiarchIncludeDirs for powerpc64le There was already partial support for multi-arch on powerpc64le, but the MultiarchIncludeDirs setting was missing. This patch adds the appropriate definition, and also extends the linux-header-search.cpp test case to verify an Ubuntu 14.04 powerpc64le tree. llvm-svn: 211359
2014-06-20 21:41:24 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
[PowerPC] Add MultiarchIncludeDirs for powerpc64le There was already partial support for multi-arch on powerpc64le, but the MultiarchIncludeDirs setting was missing. This patch adds the appropriate definition, and also extends the linux-header-search.cpp test case to verify an Ubuntu 14.04 powerpc64le tree. llvm-svn: 211359
2014-06-20 21:41:24 +08:00
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-14-04-PPC64LE %s
// CHECK-UBUNTU-14-04-PPC64LE: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-UBUNTU-14-04-PPC64LE: "-triple" "powerpc64le-unknown-linux-gnu"
// CHECK-UBUNTU-14-04-PPC64LE: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-14-04-PPC64LE: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8"
// CHECK-UBUNTU-14-04-PPC64LE: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/powerpc64le-linux-gnu/c++/4.8"
Significantly fix Clang's header search for Ubuntu (and possibly other modern Debian-based distributions) due to on-going multiarch madness. It appears that when the multiarch heeader search support went into the clang driver, it went in in a quite bad state. The order of includes completely failed to match the order exhibited by GCC, and in a specific case -- when the GCC triple and the multiarch triple don't match as with i686-linux-gnu and i386-linux-gnu -- we would absolutely fail to find the libstdc++ target-specific header files. I assume that folks who have been using Clang on Ubuntu 32-bit systems have been applying weird patches to hack around this. I can't imagine how else it could have worked. This was originally reported by a 64-bit operating system user who had a 32-bit crosscompiler installed. We tried to use that rather than the bi-arch support of the 64-bit compiler, but failed due to the triple differences. I've corrected all the wrong orderings in the existing tests and added a specific test for the multiarch triple strings that are different in a significant way. This should significantly improve the usability of Clang when checked out vanilla from upstream onto Ubuntu machines with an i686 GCC installation for whatever reason. llvm-svn: 216531
2014-08-27 16:41:41 +08:00
// CHECK-UBUNTU-14-04-PPC64LE: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../../include/c++/4.8/backward"
[PowerPC] Add MultiarchIncludeDirs for powerpc64le There was already partial support for multi-arch on powerpc64le, but the MultiarchIncludeDirs setting was missing. This patch adds the appropriate definition, and also extends the linux-header-search.cpp test case to verify an Ubuntu 14.04 powerpc64le tree. llvm-svn: 211359
2014-06-20 21:41:24 +08:00
// CHECK-UBUNTU-14-04-PPC64LE: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/powerpc64le-linux-gnu"
// CHECK-UBUNTU-14-04-PPC64LE: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-UBUNTU-14-04-PPC64LE: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// Thoroughly exercise the Debian multiarch environment.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target i686-linux-gnu -stdlib=libstdc++ \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-X86 %s
Allow any file extension for the clang binary in the linux-header-search test. Turns out this can be .exe or .EXE, depending on the build system. llvm-svn: 151490
2012-02-26 22:50:31 +08:00
// CHECK-DEBIAN-X86: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-X86: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-X86: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-X86: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.5/../../../../include/c++/4.5"
// CHECK-DEBIAN-X86: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.5/../../../../include/c++/4.5/i686-linux-gnu"
// CHECK-DEBIAN-X86: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.5/../../../../include/c++/4.5/backward"
// CHECK-DEBIAN-X86: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-X86: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-X86: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/i386-linux-gnu"
// CHECK-DEBIAN-X86: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-DEBIAN-X86: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-linux-gnu -stdlib=libstdc++ \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-X86-64 %s
Okay, makes sense to change all the occurences to match clang.EXE. llvm-svn: 151491
2012-02-26 22:55:10 +08:00
// CHECK-DEBIAN-X86-64: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-X86-64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-X86-64: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-X86-64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.5/../../../../include/c++/4.5"
// CHECK-DEBIAN-X86-64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.5/../../../../include/c++/4.5/x86_64-linux-gnu"
// CHECK-DEBIAN-X86-64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.5/../../../../include/c++/4.5/backward"
// CHECK-DEBIAN-X86-64: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-X86-64: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-X86-64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/x86_64-linux-gnu"
// CHECK-DEBIAN-X86-64: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-DEBIAN-X86-64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
The clang driver has a fairly fancy support for executing gcc instead of clang itself. This dates back to clang's early days and while it looks like some of it is still used (for kext for example), other parts are probably dead. Remove the -ccc-clang-archs option and associated code. I don't think there is any remaining setup where clang doesn't support an architecture but it can expect an working gcc cross compiler to be available. A nice side effect is that tests no longer need to differentiate architectures that are included in production builds of clang and those that are not. llvm-svn: 165545
2012-10-10 04:46:28 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target powerpc-linux-gnu -stdlib=libstdc++ \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-PPC %s
Okay, makes sense to change all the occurences to match clang.EXE. llvm-svn: 151491
2012-02-26 22:55:10 +08:00
// CHECK-DEBIAN-PPC: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-PPC: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-PPC: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-PPC: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc-linux-gnu/4.5/../../../../include/c++/4.5"
// CHECK-DEBIAN-PPC: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc-linux-gnu/4.5/../../../../include/c++/4.5/powerpc-linux-gnu"
// CHECK-DEBIAN-PPC: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc-linux-gnu/4.5/../../../../include/c++/4.5/backward"
// CHECK-DEBIAN-PPC: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-PPC: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-PPC: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/powerpc-linux-gnu"
// CHECK-DEBIAN-PPC: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-DEBIAN-PPC: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
The clang driver has a fairly fancy support for executing gcc instead of clang itself. This dates back to clang's early days and while it looks like some of it is still used (for kext for example), other parts are probably dead. Remove the -ccc-clang-archs option and associated code. I don't think there is any remaining setup where clang doesn't support an architecture but it can expect an working gcc cross compiler to be available. A nice side effect is that tests no longer need to differentiate architectures that are included in production builds of clang and those that are not. llvm-svn: 165545
2012-10-10 04:46:28 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target powerpc64-linux-gnu -stdlib=libstdc++ \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-PPC64 %s
Okay, makes sense to change all the occurences to match clang.EXE. llvm-svn: 151491
2012-02-26 22:55:10 +08:00
// CHECK-DEBIAN-PPC64: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-PPC64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-PPC64: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-PPC64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc64-linux-gnu/4.5/../../../../include/c++/4.5"
// CHECK-DEBIAN-PPC64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc64-linux-gnu/4.5/../../../../include/c++/4.5/powerpc64-linux-gnu"
// CHECK-DEBIAN-PPC64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/powerpc64-linux-gnu/4.5/../../../../include/c++/4.5/backward"
// CHECK-DEBIAN-PPC64: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-DEBIAN-PPC64: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
A follow-up to r151482 which added support for powerpc and powerpc64 Debian multiarch libraries, this should in theory add support for those platform's header search rules. I don't have a system to check this with, so review appreciated. I've added the corresponding tests referring to the debian multiarch tree. We are starting to have a relatively completely tested Linux platform for header search and library search, with several interesting peculiarities. We should point people at the debian_multiarch_tree when suggesting new tests. Folks with Debian systems that can check this for correctness, it would be much appreciated. The missing chunks I know of are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and 64-bit variants of platforms, and the MIPS and ARM Debian toolchains. llvm-svn: 151484
2012-02-26 17:21:43 +08:00
// CHECK-DEBIAN-PPC64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/powerpc64-linux-gnu"
// CHECK-DEBIAN-PPC64: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-DEBIAN-PPC64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
//
// Test Gentoo's weirdness both before and after they changed it in their GCC
// 4.6.4 release.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.6.2_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-6-2 %s
// CHECK-GENTOO-4-6-2: "{{.*}}clang{{.*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-GENTOO-4-6-2: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// CHECK-GENTOO-4-6-2: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-6-2: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4"
// CHECK-GENTOO-4-6-2: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/x86_64-pc-linux-gnu"
// CHECK-GENTOO-4-6-2: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.2/include/g++-v4/backward"
// CHECK-GENTOO-4-6-2: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-GENTOO-4-6-2: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// CHECK-GENTOO-4-6-2: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-6-2: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.6.4_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-6-4 %s
// CHECK-GENTOO-4-6-4: "{{.*}}clang{{.*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-GENTOO-4-6-4: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// CHECK-GENTOO-4-6-4: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-6-4: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4.6"
// CHECK-GENTOO-4-6-4: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4.6/x86_64-pc-linux-gnu"
// CHECK-GENTOO-4-6-4: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.4/include/g++-v4.6/backward"
// CHECK-GENTOO-4-6-4: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-GENTOO-4-6-4: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
Teach the Linux toolchain about more modern Gentoo installations of GCC which add another wrinkle to the installation of the libstdc++ headers. Add at least some basic testing of the weirdnesses of Gentoo's layout. llvm-svn: 189212
2013-08-26 16:59:53 +08:00
// CHECK-GENTOO-4-6-4: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-6-4: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
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
2016-05-08 15:59:56 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.3_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3 %s
// CHECK-GENTOO-4-9-3: "{{.*}}clang{{.*}}" "-cc1"
// CHECK-GENTOO-4-9-3: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-GENTOO-4-9-3: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-9-3: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3"
// CHECK-GENTOO-4-9-3: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/x86_64-pc-linux-gnu"
// CHECK-GENTOO-4-9-3: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/backward"
// CHECK-GENTOO-4-9-3: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-GENTOO-4-9-3: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-GENTOO-4-9-3: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-3: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
//
[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
2016-10-25 23:07:41 +08:00
// Test support for Gentoo's gcc-config -- clang should prefer the older
// (4.9.3) version over the newer (5.4.0) due to preference specified
// in /etc/env.d/gcc/x86_64-pc-linux-gnu.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3 %s
//
[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
2016-12-12 23:07:43 +08:00
// Test that gcc-config support does not break multilib.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnux32 -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3-X32 %s
// CHECK-GENTOO-4-9-3-X32: "{{.*}}clang{{.*}}" "-cc1"
// CHECK-GENTOO-4-9-3-X32: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-GENTOO-4-9-3-X32: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-9-3-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3"
// CHECK-GENTOO-4-9-3-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/x86_64-pc-linux-gnu/x32"
// CHECK-GENTOO-4-9-3-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/backward"
// CHECK-GENTOO-4-9-3-X32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-GENTOO-4-9-3-X32: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-GENTOO-4-9-3-X32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-3-X32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target i386-unknown-linux-gnu -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3-32 %s
// CHECK-GENTOO-4-9-3-32: "{{.*}}clang{{.*}}" "-cc1"
// CHECK-GENTOO-4-9-3-32: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-GENTOO-4-9-3-32: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-9-3-32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3"
// CHECK-GENTOO-4-9-3-32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/x86_64-pc-linux-gnu/32"
// CHECK-GENTOO-4-9-3-32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/include/g++-v4.9.3/backward"
// CHECK-GENTOO-4-9-3-32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-GENTOO-4-9-3-32: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-GENTOO-4-9-3-32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-3-32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
[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
2018-04-08 03:59:58 +08:00
// Test support for parsing Gentoo's gcc-config -- clang should parse the
// /etc/env.d/gcc/config-x86_64-pc-linux-gnu file to find CURRENT gcc used.
// Then should pick the multilibs from version 4.9.x specified in
// /etc/env.d/gcc/x86_64-pc-linux-gnu-4.9.3.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.x_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-X %s
//
// CHECK-GENTOO-4-9-X: "{{.*}}clang{{.*}}" "-cc1"
// CHECK-GENTOO-4-9-X: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-GENTOO-4-9-X: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-9-X: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3"
// CHECK-GENTOO-4-9-X: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3/x86_64-pc-linux-gnu"
// CHECK-GENTOO-4-9-X: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3/backward"
// CHECK-GENTOO-4-9-X: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-GENTOO-4-9-X: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-GENTOO-4-9-X: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-X: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnux32 -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.x_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-X-X32 %s
// CHECK-GENTOO-4-9-X-X32: "{{.*}}clang{{.*}}" "-cc1"
// CHECK-GENTOO-4-9-X-X32: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-GENTOO-4-9-X-X32: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-9-X-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3"
// CHECK-GENTOO-4-9-X-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3/x86_64-pc-linux-gnu/x32"
// CHECK-GENTOO-4-9-X-X32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3/backward"
// CHECK-GENTOO-4-9-X-X32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-GENTOO-4-9-X-X32: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-GENTOO-4-9-X-X32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-X-X32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target i386-unknown-linux-gnu -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.x_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-X-32 %s
// CHECK-GENTOO-4-9-X-32: "{{.*}}clang{{.*}}" "-cc1"
// CHECK-GENTOO-4-9-X-32: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-GENTOO-4-9-X-32: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-GENTOO-4-9-X-32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3"
// CHECK-GENTOO-4-9-X-32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3/x86_64-pc-linux-gnu/32"
// CHECK-GENTOO-4-9-X-32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4.9.3/backward"
// CHECK-GENTOO-4-9-X-32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-GENTOO-4-9-X-32: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-GENTOO-4-9-X-32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-X-32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// Check header search on Debian 6 / MIPS64
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target mips64-unknown-linux-gnuabi64 -stdlib=libstdc++ \
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// RUN: --sysroot=%S/Inputs/debian_6_mips64_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPS64-GNUABI %s
// CHECK-MIPS64-GNUABI: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-MIPS64-GNUABI: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// CHECK-MIPS64-GNUABI: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-MIPS64-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../../../include/c++/4.9"
// CHECK-MIPS64-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../../../include/c++/4.9/mips64-linux-gnuabi64"
// CHECK-MIPS64-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../../../include/c++/4.9/backward"
// CHECK-MIPS64-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-MIPS64-GNUABI: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// CHECK-MIPS64-GNUABI: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/mips64-linux-gnuabi64"
// CHECK-MIPS64-GNUABI: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-MIPS64-GNUABI: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
//
// Check header search on Debian 6 / MIPS64
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target mips64el-unknown-linux-gnuabi64 -stdlib=libstdc++ \
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// RUN: --sysroot=%S/Inputs/debian_6_mips64_tree \
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. llvm-svn: 225182
2015-01-06 01:07:42 +08:00
// RUN: --gcc-toolchain="" \
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPS64EL-GNUABI %s
// CHECK-MIPS64EL-GNUABI: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-MIPS64EL-GNUABI: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// CHECK-MIPS64EL-GNUABI: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-MIPS64EL-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../../../include/c++/4.9"
// CHECK-MIPS64EL-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../../../include/c++/4.9/mips64el-linux-gnuabi64"
// CHECK-MIPS64EL-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../../../include/c++/4.9/backward"
// CHECK-MIPS64EL-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Avoid testing for a particular choice of resource dir. Without this patch, this test was accidentally testing that CLANG_RESOURCE_DIR, CLANG_LIBDIR_SUFFIX, and CLANG_VERSION_STRING were set to a particular set of values. The test was also getting pretty hairy since it was attempting to craft a regular expression that covered "all" possible combinations of settings for these configure-time constants. Clean it up by directly capturing the resource directory in a FileCheck variable. llvm-svn: 227310
2015-01-28 22:19:08 +08:00
// CHECK-MIPS64EL-GNUABI: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver][Mips] Support mips64-linux-gnuabi64 / mips64el-linux-gnuabi64 target triples. The patch fixes the bug #19869. http://llvm.org/bugs/show_bug.cgi?id=19869 llvm-svn: 211619
2014-06-25 03:00:12 +08:00
// CHECK-MIPS64EL-GNUABI: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/mips64el-linux-gnuabi64"
// CHECK-MIPS64EL-GNUABI: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-MIPS64EL-GNUABI: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
[SPARC] Add multiarch include paths. Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9 layout for sparc (32bit), sparc (32bit) with lib64 multilib, and sparc64. The test cases added here also cover r239047, which fixed the linker paths. llvm-svn: 239154
2015-06-05 21:44:43 +08:00
// Check header search on Debian 8 / Sparc
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target sparc-unknown-linux-gnu -stdlib=libstdc++ \
[SPARC] Add multiarch include paths. Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9 layout for sparc (32bit), sparc (32bit) with lib64 multilib, and sparc64. The test cases added here also cover r239047, which fixed the linker paths. llvm-svn: 239154
2015-06-05 21:44:43 +08:00
// RUN: --sysroot=%S/Inputs/debian_8_sparc_multilib_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-SPARC32 %s
// CHECK-DEBIAN-SPARC32: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-DEBIAN-SPARC32: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-DEBIAN-SPARC32: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-SPARC32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../include/c++/4.9"
// CHECK-DEBIAN-SPARC32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../include/sparc-linux-gnu/c++/4.9"
// CHECK-DEBIAN-SPARC32: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../include/c++/4.9/backward"
// CHECK-DEBIAN-SPARC32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-DEBIAN-SPARC32: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-DEBIAN-SPARC32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/sparc-linux-gnu"
// CHECK-DEBIAN-SPARC32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-DEBIAN-SPARC32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
// Check header search on Debian 8 / Sparc, with the oldstyle multilib packages
// RUN: %clang -no-canonical-prefixes -m64 %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target sparc-unknown-linux-gnu -stdlib=libstdc++ \
[SPARC] Add multiarch include paths. Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9 layout for sparc (32bit), sparc (32bit) with lib64 multilib, and sparc64. The test cases added here also cover r239047, which fixed the linker paths. llvm-svn: 239154
2015-06-05 21:44:43 +08:00
// RUN: --sysroot=%S/Inputs/debian_8_sparc_multilib_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-SPARC32-LIB64 %s
// CHECK-DEBIAN-SPARC32-LIB64: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-DEBIAN-SPARC32-LIB64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-DEBIAN-SPARC32-LIB64: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-SPARC32-LIB64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../include/c++/4.9"
// CHECK-DEBIAN-SPARC32-LIB64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../include/sparc-linux-gnu/c++/4.9/64"
// CHECK-DEBIAN-SPARC32-LIB64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../include/c++/4.9/backward"
// CHECK-DEBIAN-SPARC32-LIB64: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-DEBIAN-SPARC32-LIB64: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
/* TODO: GCC 4.9 includes the following dir in its search path, which
seems questionable. Clang doesn't. Not sure if clang should be
doing that too. */
// CHECK-DEBIAN-SPARC32-LIB64-todo: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/sparc-linux-gnu"
// CHECK-DEBIAN-SPARC32-LIB64: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-DEBIAN-SPARC32-LIB64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
// Check header search on Debian 8 / Sparc64
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
tests: Add explicit -stdlib=libstdc++ to tests that require it This will be needed for the next commit that allows to switch the default C++ library which would otherwise make these tests fail. llvm-svn: 260661
2016-02-12 15:48:28 +08:00
// RUN: -target sparc64-unknown-linux-gnu -stdlib=libstdc++ \
[SPARC] Add multiarch include paths. Adds tests verifying the proper dirs are found in the Debian 8/GCC4.9 layout for sparc (32bit), sparc (32bit) with lib64 multilib, and sparc64. The test cases added here also cover r239047, which fixed the linker paths. llvm-svn: 239154
2015-06-05 21:44:43 +08:00
// RUN: --sysroot=%S/Inputs/debian_8_sparc64_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-SPARC64 %s
// CHECK-DEBIAN-SPARC64: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-DEBIAN-SPARC64: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-DEBIAN-SPARC64: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-SPARC64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../../../include/c++/4.9"
// CHECK-DEBIAN-SPARC64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../../../include/sparc64-linux-gnu/c++/4.9"
// CHECK-DEBIAN-SPARC64: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../../../include/c++/4.9/backward"
// CHECK-DEBIAN-SPARC64: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-DEBIAN-SPARC64: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-DEBIAN-SPARC64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/sparc64-linux-gnu"
// CHECK-DEBIAN-SPARC64: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-DEBIAN-SPARC64: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
[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
2018-07-31 03:44:13 +08:00
// Check header search on OpenEmbedded ARM.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
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
2018-07-31 19:36:14 +08:00
// RUN: -target arm-oe-linux-gnueabi -stdlib=libstdc++ \
[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
2018-07-31 03:44:13 +08:00
// RUN: --sysroot=%S/Inputs/openembedded_arm_linux_tree \
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
2018-08-07 16:10:33 +08:00
// RUN: --gcc-toolchain="" \
[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
2018-07-31 03:44:13 +08:00
// RUN: | FileCheck --check-prefix=CHECK-OE-ARM %s
// CHECK-OE-ARM: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-OE-ARM: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-OE-ARM: "-internal-isystem" "[[SYSROOT]]/usr/lib/arm-oe-linux-gnueabi/6.3.0/../../../include/c++/6.3.0"
// CHECK-OE-ARM: "-internal-isystem" "[[SYSROOT]]/usr/lib/arm-oe-linux-gnueabi/6.3.0/../../../include/c++/6.3.0/backward"
// Check header search on OpenEmbedded AArch64.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
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
2018-07-31 19:36:14 +08:00
// RUN: -target aarch64-oe-linux -stdlib=libstdc++ \
[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
2018-07-31 03:44:13 +08:00
// RUN: --sysroot=%S/Inputs/openembedded_aarch64_linux_tree \
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
2018-08-07 16:10:33 +08:00
// RUN: --gcc-toolchain="" \
[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
2018-07-31 03:44:13 +08:00
// RUN: | FileCheck --check-prefix=CHECK-OE-AARCH64 %s
// CHECK-OE-AARCH64: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-OE-AARCH64: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-OE-AARCH64: "-internal-isystem" "[[SYSROOT]]/usr/lib64/aarch64-oe-linux/6.3.0/../../../include/c++/6.3.0"
// CHECK-OE-AARCH64: "-internal-isystem" "[[SYSROOT]]/usr/lib64/aarch64-oe-linux/6.3.0/../../../include/c++/6.3.0/backward"
[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
2018-11-14 05:38:45 +08:00
// Check header search with Cray's gcc package.
// RUN: %clang -no-canonical-prefixes %s -### -fsyntax-only 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/cray_suse_gcc_tree \
// RUN: --gcc-toolchain="%S/Inputs/cray_suse_gcc_tree/opt/gcc/8.2.0/snos" \
// RUN: | FileCheck --check-prefix=CHECK-CRAY-X86 %s
// CHECK-CRAY-X86: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-CRAY-X86: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-CRAY-X86: "-internal-isystem" "[[SYSROOT]]/opt/gcc/8.2.0/snos/lib/gcc/x86_64-suse-linux/8.2.0/../../../../include/g++"
// CHECK-CRAY-X86: "-internal-isystem" "[[SYSROOT]]/opt/gcc/8.2.0/snos/lib/gcc/x86_64-suse-linux/8.2.0/../../../../include/g++/backward"