mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-26 11:56:07 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/clang/test/Driver/linux-header-search.cpp

323 lines
21 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 03:46:20 +00:00
// General tests that the header search paths detected by the driver and passed
// to CC1 are sane.
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
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 09:42:24 +00:00
// Test a simulated installation of libc++ on Linux, both through sysroot and
// the installation path of Clang.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu \
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 09:42:24 +00:00
// 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 03:11:52 +00: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 09:42:24 +00:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-SYSROOT %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-BASIC-LIBCXX-SYSROOT: "-cc1"
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 09:42:24 +00:00
// CHECK-BASIC-LIBCXX-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
[driver] Conditionally include installed libc++ headers for Android https://reviews.llvm.org/D71154 prevented Clang from search for libc++ headers installed alongside the driver when targeting Android. The motivation was the NDK's use of a different libc++ inline namespace (`__ndk1` instead of the standard `__1`), which made regular libc++ headers incompatible with the NDK's libc++ library. Since then, libc++ has gained the ability to install its `__config_site` header (which controls the inline namespace, among other things) to a per-target include directory, which enables per-target customizations. If this directory is present, the user has expressly built libc++ for Android, and we should use those headers. The motivation is that, with the current setup, if a user builds their own libc++ for Android, they'll use the library they built themselves but the NDK's headers instead of their own, which is surprising at best and can cause all sorts of problems (e.g. if you built your own libc++ with a different ABI configuration). It's important to match the headers and libraries in that scenario, and checking for an Android per-target include directory lets us do so without regressing the original scenario which https://reviews.llvm.org/D71154 was addressing. While I'm here, switch to using sys::path::append instead of slashes directly, to get system path separators on Windows, which is consistent with how library paths are constructed (and that consistency will be important in a follow-up, where we use a common search function for the include and library path construction). (As an aside, one of the motivations for https://reviews.llvm.org/D71154 was to support targeting both Android and Apple platforms, which expected libc++ headers to be provided by the toolcain at the time. Apple has since switched to including libc++ headers in the platform SDK instead of in the toolchain, so that specific motivation no longer applies either.) Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D159292
2023-08-30 15:11:07 -07:00
// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]][[SEP:/|\\\\]]usr[[SEP]]include[[SEP]]x86_64-unknown-linux-gnu[[SEP]]c++[[SEP]]v1"
// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]][[SEP]]usr[[SEP]]include[[SEP]]c++[[SEP]]v1"
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 09:42:24 +00:00
// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
[Clang][Driver] Fix include paths for `--sysroot /` on Linux Currently if `--sysroot /` is passed to the Clang driver, the include paths generated by the Clang driver will start with a double slash: `//usr/include/...`. If VFS is used to inject files into the include paths (for example, the Swift compiler does this), VFS will get confused and the injected files won't be visible. This change makes sure that the include paths start with a single slash. Fixes #28283. Differential Revision: https://reviews.llvm.org/D126289
2022-05-24 12:00:50 +01:00
// Test include paths when the sysroot path ends with `/`.
// RUN: %clang -### %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 \
// RUN: -resource-dir=%S/Inputs/resource_dir \
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree/ \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-SYSROOT-SLASH %s
// CHECK-BASIC-LIBCXX-SYSROOT-SLASH: "-cc1"
// CHECK-BASIC-LIBCXX-SYSROOT-SLASH-SAME: "-isysroot" "[[SYSROOT:[^"]+/]]"
[driver] Conditionally include installed libc++ headers for Android https://reviews.llvm.org/D71154 prevented Clang from search for libc++ headers installed alongside the driver when targeting Android. The motivation was the NDK's use of a different libc++ inline namespace (`__ndk1` instead of the standard `__1`), which made regular libc++ headers incompatible with the NDK's libc++ library. Since then, libc++ has gained the ability to install its `__config_site` header (which controls the inline namespace, among other things) to a per-target include directory, which enables per-target customizations. If this directory is present, the user has expressly built libc++ for Android, and we should use those headers. The motivation is that, with the current setup, if a user builds their own libc++ for Android, they'll use the library they built themselves but the NDK's headers instead of their own, which is surprising at best and can cause all sorts of problems (e.g. if you built your own libc++ with a different ABI configuration). It's important to match the headers and libraries in that scenario, and checking for an Android per-target include directory lets us do so without regressing the original scenario which https://reviews.llvm.org/D71154 was addressing. While I'm here, switch to using sys::path::append instead of slashes directly, to get system path separators on Windows, which is consistent with how library paths are constructed (and that consistency will be important in a follow-up, where we use a common search function for the include and library path construction). (As an aside, one of the motivations for https://reviews.llvm.org/D71154 was to support targeting both Android and Apple platforms, which expected libc++ headers to be provided by the toolcain at the time. Apple has since switched to including libc++ headers in the platform SDK instead of in the toolchain, so that specific motivation no longer applies either.) Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D159292
2023-08-30 15:11:07 -07:00
// CHECK-BASIC-LIBCXX-SYSROOT-SLASH-SAME: "-internal-isystem" "[[SYSROOT]]usr[[SEP:/|\\\\]]include[[SEP]]x86_64-unknown-linux-gnu[[SEP]]c++[[SEP]]v1"
// CHECK-BASIC-LIBCXX-SYSROOT-SLASH-SAME: "-internal-isystem" "[[SYSROOT]]usr[[SEP]]include[[SEP]]c++[[SEP]]v1"
[Clang][Driver] Fix include paths for `--sysroot /` on Linux Currently if `--sysroot /` is passed to the Clang driver, the include paths generated by the Clang driver will start with a double slash: `//usr/include/...`. If VFS is used to inject files into the include paths (for example, the Swift compiler does this), VFS will get confused and the injected files won't be visible. This change makes sure that the include paths start with a single slash. Fixes #28283. Differential Revision: https://reviews.llvm.org/D126289
2022-05-24 12:00:50 +01:00
// CHECK-BASIC-LIBCXX-SYSROOT-SLASH-SAME: "-internal-isystem" "[[SYSROOT]]usr/local/include"
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu \
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 09:42:24 +00:00
// 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 03:11:52 +00: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 09:42:24 +00:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-INSTALL %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-BASIC-LIBCXX-INSTALL: "-cc1"
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 09:42:24 +00:00
// CHECK-BASIC-LIBCXX-INSTALL: "-isysroot" "[[SYSROOT:[^"]+]]"
[driver] Conditionally include installed libc++ headers for Android https://reviews.llvm.org/D71154 prevented Clang from search for libc++ headers installed alongside the driver when targeting Android. The motivation was the NDK's use of a different libc++ inline namespace (`__ndk1` instead of the standard `__1`), which made regular libc++ headers incompatible with the NDK's libc++ library. Since then, libc++ has gained the ability to install its `__config_site` header (which controls the inline namespace, among other things) to a per-target include directory, which enables per-target customizations. If this directory is present, the user has expressly built libc++ for Android, and we should use those headers. The motivation is that, with the current setup, if a user builds their own libc++ for Android, they'll use the library they built themselves but the NDK's headers instead of their own, which is surprising at best and can cause all sorts of problems (e.g. if you built your own libc++ with a different ABI configuration). It's important to match the headers and libraries in that scenario, and checking for an Android per-target include directory lets us do so without regressing the original scenario which https://reviews.llvm.org/D71154 was addressing. While I'm here, switch to using sys::path::append instead of slashes directly, to get system path separators on Windows, which is consistent with how library paths are constructed (and that consistency will be important in a follow-up, where we use a common search function for the include and library path construction). (As an aside, one of the motivations for https://reviews.llvm.org/D71154 was to support targeting both Android and Apple platforms, which expected libc++ headers to be provided by the toolcain at the time. Apple has since switched to including libc++ headers in the platform SDK instead of in the toolchain, so that specific motivation no longer applies either.) Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D159292
2023-08-30 15:11:07 -07:00
// CHECK-BASIC-LIBCXX-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/bin[[SEP:/|\\\\]]..[[SEP]]include[[SEP]]x86_64-unknown-linux-gnu[[SEP]]c++[[SEP]]v1"
// CHECK-BASIC-LIBCXX-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/bin[[SEP]]..[[SEP]]include[[SEP]]c++[[SEP]]v1"
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 09:42:24 +00:00
// CHECK-BASIC-LIBCXX-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu \
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// 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 03:11:52 +00: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-09 21:10:54 +00:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-SYSROOT %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-cc1"
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
[driver] Conditionally include installed libc++ headers for Android https://reviews.llvm.org/D71154 prevented Clang from search for libc++ headers installed alongside the driver when targeting Android. The motivation was the NDK's use of a different libc++ inline namespace (`__ndk1` instead of the standard `__1`), which made regular libc++ headers incompatible with the NDK's libc++ library. Since then, libc++ has gained the ability to install its `__config_site` header (which controls the inline namespace, among other things) to a per-target include directory, which enables per-target customizations. If this directory is present, the user has expressly built libc++ for Android, and we should use those headers. The motivation is that, with the current setup, if a user builds their own libc++ for Android, they'll use the library they built themselves but the NDK's headers instead of their own, which is surprising at best and can cause all sorts of problems (e.g. if you built your own libc++ with a different ABI configuration). It's important to match the headers and libraries in that scenario, and checking for an Android per-target include directory lets us do so without regressing the original scenario which https://reviews.llvm.org/D71154 was addressing. While I'm here, switch to using sys::path::append instead of slashes directly, to get system path separators on Windows, which is consistent with how library paths are constructed (and that consistency will be important in a follow-up, where we use a common search function for the include and library path construction). (As an aside, one of the motivations for https://reviews.llvm.org/D71154 was to support targeting both Android and Apple platforms, which expected libc++ headers to be provided by the toolcain at the time. Apple has since switched to including libc++ headers in the platform SDK instead of in the toolchain, so that specific motivation no longer applies either.) Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D159292
2023-08-30 15:11:07 -07:00
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]][[SEP:/|\\\\]]usr[[SEP]]include[[SEP]]x86_64-unknown-linux-gnu[[SEP]]c++[[SEP]]v2"
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]][[SEP]]usr[[SEP]]include[[SEP]]c++[[SEP]]v2"
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// CHECK-BASIC-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu \
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// 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 03:11:52 +00: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-09 21:10:54 +00:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxxv2_tree \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXXV2-INSTALL %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-BASIC-LIBCXXV2-INSTALL: "-cc1"
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// CHECK-BASIC-LIBCXXV2-INSTALL: "-isysroot" "[[SYSROOT:[^"]+]]"
[driver] Conditionally include installed libc++ headers for Android https://reviews.llvm.org/D71154 prevented Clang from search for libc++ headers installed alongside the driver when targeting Android. The motivation was the NDK's use of a different libc++ inline namespace (`__ndk1` instead of the standard `__1`), which made regular libc++ headers incompatible with the NDK's libc++ library. Since then, libc++ has gained the ability to install its `__config_site` header (which controls the inline namespace, among other things) to a per-target include directory, which enables per-target customizations. If this directory is present, the user has expressly built libc++ for Android, and we should use those headers. The motivation is that, with the current setup, if a user builds their own libc++ for Android, they'll use the library they built themselves but the NDK's headers instead of their own, which is surprising at best and can cause all sorts of problems (e.g. if you built your own libc++ with a different ABI configuration). It's important to match the headers and libraries in that scenario, and checking for an Android per-target include directory lets us do so without regressing the original scenario which https://reviews.llvm.org/D71154 was addressing. While I'm here, switch to using sys::path::append instead of slashes directly, to get system path separators on Windows, which is consistent with how library paths are constructed (and that consistency will be important in a follow-up, where we use a common search function for the include and library path construction). (As an aside, one of the motivations for https://reviews.llvm.org/D71154 was to support targeting both Android and Apple platforms, which expected libc++ headers to be provided by the toolcain at the time. Apple has since switched to including libc++ headers in the platform SDK instead of in the toolchain, so that specific motivation no longer applies either.) Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D159292
2023-08-30 15:11:07 -07:00
// CHECK-BASIC-LIBCXXV2-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/bin[[SEP:/|\\\\]]..[[SEP]]include[[SEP]]x86_64-unknown-linux-gnu[[SEP]]c++[[SEP]]v2"
// CHECK-BASIC-LIBCXXV2-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/bin[[SEP]]..[[SEP]]include[[SEP]]c++[[SEP]]v2"
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// CHECK-BASIC-LIBCXXV2-INSTALL: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
[Clang][Driver] Fix include paths for `--sysroot /` on Linux Currently if `--sysroot /` is passed to the Clang driver, the include paths generated by the Clang driver will start with a double slash: `//usr/include/...`. If VFS is used to inject files into the include paths (for example, the Swift compiler does this), VFS will get confused and the injected files won't be visible. This change makes sure that the include paths start with a single slash. Fixes #28283. Differential Revision: https://reviews.llvm.org/D126289
2022-05-24 12:00:50 +01:00
// Test Linux with libstdc++ when the sysroot path ends with `/`.
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu \
// RUN: -stdlib=libstdc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
// RUN: -resource-dir=%S/Inputs/resource_dir \
// RUN: --sysroot=%S/Inputs/basic_linux_libstdcxx_tree/ \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBSTDCXX-SYSROOT-SLASH %s
// CHECK-BASIC-LIBSTDCXX-SYSROOT-SLASH: "-cc1"
// CHECK-BASIC-LIBSTDCXX-SYSROOT-SLASH-SAME: "-isysroot" "[[SYSROOT:[^"]+/]]"
// CHECK-BASIC-LIBSTDCXX-SYSROOT-SLASH-SAME: "-internal-isystem" "[[SYSROOT]]usr/lib/gcc/x86_64-unknown-linux-gnu/4.8/../../../../x86_64-unknown-linux-gnu/include"
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// Test Linux with both libc++ and libstdc++ installed.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu \
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// 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 03:11:52 +00: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-09 21:10:54 +00:00
// RUN: --sysroot=%S/Inputs/basic_linux_libstdcxx_libcxxv2_tree \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-cc1"
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
[driver] Conditionally include installed libc++ headers for Android https://reviews.llvm.org/D71154 prevented Clang from search for libc++ headers installed alongside the driver when targeting Android. The motivation was the NDK's use of a different libc++ inline namespace (`__ndk1` instead of the standard `__1`), which made regular libc++ headers incompatible with the NDK's libc++ library. Since then, libc++ has gained the ability to install its `__config_site` header (which controls the inline namespace, among other things) to a per-target include directory, which enables per-target customizations. If this directory is present, the user has expressly built libc++ for Android, and we should use those headers. The motivation is that, with the current setup, if a user builds their own libc++ for Android, they'll use the library they built themselves but the NDK's headers instead of their own, which is surprising at best and can cause all sorts of problems (e.g. if you built your own libc++ with a different ABI configuration). It's important to match the headers and libraries in that scenario, and checking for an Android per-target include directory lets us do so without regressing the original scenario which https://reviews.llvm.org/D71154 was addressing. While I'm here, switch to using sys::path::append instead of slashes directly, to get system path separators on Windows, which is consistent with how library paths are constructed (and that consistency will be important in a follow-up, where we use a common search function for the include and library path construction). (As an aside, one of the motivations for https://reviews.llvm.org/D71154 was to support targeting both Android and Apple platforms, which expected libc++ headers to be provided by the toolcain at the time. Apple has since switched to including libc++ headers in the platform SDK instead of in the toolchain, so that specific motivation no longer applies either.) Reviewed By: phosek Differential Revision: https://reviews.llvm.org/D159292
2023-08-30 15:11:07 -07:00
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]][[SEP:/|\\\\]]usr[[SEP]]include[[SEP]]x86_64-unknown-linux-gnu[[SEP]]c++[[SEP]]v2"
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]][[SEP]]usr[[SEP]]include[[SEP]]c++[[SEP]]v2"
Extend linux header search to find libc++ headers in c++/vN for any N. llvm-svn: 252514
2015-11-09 21:10:54 +00:00
// CHECK-BASIC-LIBSTDCXX-LIBCXXV2-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
[test] Delete obsoleted debian_multiarch_tree and ubuntu_13.04_multiarch_tree They are quite outdated. Delete them to avoid unnecessary test churn.
2021-03-21 15:23:49 -07:00
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 08:59:53 +00:00
// Test Gentoo's weirdness both before and after they changed it in their GCC
// 4.6.4 release.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// 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 08:59:53 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.6.2_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-6-2 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-6-2: "-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 14:19:08 +00: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 08:59:53 +00: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"
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 14:19:08 +00:00
// CHECK-GENTOO-4-6-2: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-6-2: "-internal-isystem" "[[SYSROOT]]/usr/local/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 08:59:53 +00:00
// CHECK-GENTOO-4-6-2: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-6-2: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// 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 08:59:53 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.6.4_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-6-4 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-6-4: "-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 14:19:08 +00: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 08:59:53 +00: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"
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 14:19:08 +00:00
// CHECK-GENTOO-4-6-4: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-6-4: "-internal-isystem" "[[SYSROOT]]/usr/local/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 08:59:53 +00:00
// CHECK-GENTOO-4-6-4: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-6-4: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu -stdlib=libstdc++ \
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 07:59:56 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.3_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-9-3: "-cc1"
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 07:59:56 +00:00
// 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" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-9-3: "-internal-isystem" "[[SYSROOT]]/usr/local/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 07:59:56 +00:00
// CHECK-GENTOO-4-9-3: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-3: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07: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 15:07:41 +00: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.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu -stdlib=libstdc++ \
[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 15:07:41 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3 %s
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[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 15:07:43 +00:00
// Test that gcc-config support does not break multilib.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnux32 -stdlib=libstdc++ \
[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 15:07:43 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3-X32 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-9-3-X32: "-cc1"
[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 15:07:43 +00:00
// 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" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-9-3-X32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
[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 15:07:43 +00:00
// CHECK-GENTOO-4-9-3-X32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-3-X32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=i386-unknown-linux-gnu -stdlib=libstdc++ \
[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 15:07:43 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-3-32 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-9-3-32: "-cc1"
[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 15:07:43 +00:00
// 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" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-9-3-32: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
[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 15:07:43 +00:00
// CHECK-GENTOO-4-9-3-32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-3-32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[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-07 19:59:58 +00: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.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu -stdlib=libstdc++ \
[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-07 19:59:58 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.x_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-X %s
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-9-X: "-cc1"
[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-07 19:59:58 +00:00
// 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" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-9-X: "-internal-isystem" "[[SYSROOT]]/usr/local/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-07 19:59:58 +00:00
// CHECK-GENTOO-4-9-X: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-X: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnux32 -stdlib=libstdc++ \
[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-07 19:59:58 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.x_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-X-X32 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-9-X-X32: "-cc1"
[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-07 19:59:58 +00:00
// 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" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-9-X-X32: "-internal-isystem" "[[SYSROOT]]/usr/local/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-07 19:59:58 +00:00
// CHECK-GENTOO-4-9-X-X32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-X-X32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=i386-unknown-linux-gnu -stdlib=libstdc++ \
[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-07 19:59:58 +00:00
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_4.9.x_tree \
// RUN: | FileCheck --check-prefix=CHECK-GENTOO-4-9-X-32 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-GENTOO-4-9-X-32: "-cc1"
[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-07 19:59:58 +00:00
// 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" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-GENTOO-4-9-X-32: "-internal-isystem" "[[SYSROOT]]/usr/local/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-07 19:59:58 +00:00
// CHECK-GENTOO-4-9-X-32: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-GENTOO-4-9-X-32: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[Clang][Driver] Handle LoongArch multiarch tuples This follows v1.00 of the [[ https://loongson.github.io/LoongArch-Documentation/LoongArch-toolchain-conventions-EN.html | LoongArch Toolchain Conventions ]], but notably with [[ https://github.com/loongson/LoongArch-Documentation/pull/80 | this patch ]] applied (a proper version bump to v2.00 was not done, so it is indistinguishable from the "original" but now incompatible v1.00 otherwise). Only `loongarch64` is implemented in `Linux::getMultiarchTriple` because support for LA32 and ILP32* ABIs are incomplete right now. The Debian sysroot layout is based on Han Gao's recent porting effort, specifically the ghcr.io/rabenda/beige:loong64-v23-preview-20230330 container image. Reviewed By: SixWeining Differential Revision: https://reviews.llvm.org/D142688
2023-04-24 15:18:46 +08:00
// Check header search on Debian loong64
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=loongarch64-unknown-linux-gnu -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/debian_loong64_tree \
// RUN: | FileCheck --check-prefix=CHECK-LOONG64-GNU %s
//
// Check that "-gnuf64" is seen as "-gnu" for loong64.
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=loongarch64-unknown-linux-gnuf64 -stdlib=libstdc++ \
// RUN: --sysroot=%S/Inputs/debian_loong64_tree \
// RUN: | FileCheck --check-prefix=CHECK-LOONG64-GNU %s
// CHECK-LOONG64-GNU: "-cc1"
// CHECK-LOONG64-GNU: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-LOONG64-GNU: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-LOONG64-GNU: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/loongarch64-linux-gnu/13/../../../../include/c++/13"
// CHECK-LOONG64-GNU: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/loongarch64-linux-gnu/13/../../../../include/c++/13/loongarch64-linux-gnu"
// CHECK-LOONG64-GNU: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/loongarch64-linux-gnu/13/../../../../include/c++/13/backward"
// CHECK-LOONG64-GNU: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
// CHECK-LOONG64-GNU: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-LOONG64-GNU: "-internal-isystem" "[[SYSROOT]]/usr/lib/gcc/loongarch64-linux-gnu/13/../../../../loongarch64-linux-gnu/include"
// CHECK-LOONG64-GNU: "-internal-externc-isystem" "[[SYSROOT]]/usr/include/loongarch64-linux-gnu"
// CHECK-LOONG64-GNU: "-internal-externc-isystem" "[[SYSROOT]]/include"
// CHECK-LOONG64-GNU: "-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-24 19:00:12 +00:00
// Check header search on Debian 6 / MIPS64
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// 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-24 19:00:12 +00:00
// RUN: --sysroot=%S/Inputs/debian_6_mips64_tree \
// RUN: | FileCheck --check-prefix=CHECK-MIPS64-GNUABI %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-MIPS64-GNUABI: "-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 14:19:08 +00: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-24 19:00:12 +00: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"
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 14:19:08 +00:00
// CHECK-MIPS64-GNUABI: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-MIPS64-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/local/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-24 19:00:12 +00: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"
Revert "[Driver][test] Replace ^//$ with empty string" This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
2022-06-24 13:52:27 -07:00
//
[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-24 19:00:12 +00:00
// Check header search on Debian 6 / MIPS64
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// 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-24 19:00:12 +00:00
// RUN: --sysroot=%S/Inputs/debian_6_mips64_tree \
// RUN: | FileCheck --check-prefix=CHECK-MIPS64EL-GNUABI %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-MIPS64EL-GNUABI: "-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 14:19:08 +00: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-24 19:00:12 +00: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"
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 14:19:08 +00:00
// CHECK-MIPS64EL-GNUABI: "-internal-isystem" "[[RESOURCE_DIR]]{{/|\\\\}}include"
[Driver] Linux.cpp: move resource directory before /usr/local/include for non-musl This follows GCC and simplifies code. /usr/local/include and TOOL_INCLUDE_DIR should not conflict with the resource directory include so users should not observe any difference.
2021-03-28 12:44:21 -07:00
// CHECK-MIPS64EL-GNUABI: "-internal-isystem" "[[SYSROOT]]/usr/local/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-24 19:00:12 +00: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 13:44:43 +00:00
[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-30 19:44:13 +00:00
// Check header search on OpenEmbedded ARM.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// 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-30 19:44:13 +00:00
// RUN: --sysroot=%S/Inputs/openembedded_arm_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-OE-ARM %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-OE-ARM: "-cc1"
[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-30 19:44:13 +00:00
// 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.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// 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-30 19:44:13 +00:00
// RUN: --sysroot=%S/Inputs/openembedded_aarch64_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-OE-AARCH64 %s
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-OE-AARCH64: "-cc1"
[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-30 19:44:13 +00:00
// 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-13 21:38:45 +00:00
// Check header search with Cray's gcc package.
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// RUN: %clang -### %s -fsyntax-only 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu -stdlib=libstdc++ \
[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-13 21:38:45 +00:00
// 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
[Driver][test] Remove unneeded -no-canonical-prefixes and use preferred --target= Similar to D119309
2022-05-01 20:44:13 -07:00
// CHECK-CRAY-X86: "-cc1"
[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-13 21:38:45 +00:00
// 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"
Reference in New Issue Copy Permalink