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-ld.c

1786 lines
102 KiB
C
Raw Normal View History

Add initial support for applying the sysroot to library search paths. This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
2011-10-03 14:41:08 +08:00
// General tests that ld invocations on Linux targets sane. Note that we use
// sysroot to make these tests independent of the host system.
Add a test that ensures we get the basic multilib '-L' flags to 'ld' invocations on Linux. llvm-svn: 140909
2011-10-01 08:37:39 +08:00
//
Add initial support for applying the sysroot to library search paths. This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
2011-10-03 14:41:08 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux \
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="" \
Add initial support for applying the sysroot to library search paths. This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
2011-10-03 14:41:08 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
Add a test that ensures we get the basic multilib '-L' flags to 'ld' invocations on Linux. llvm-svn: 140909
2011-10-01 08:37:39 +08:00
// RUN: | FileCheck --check-prefix=CHECK-LD-32 %s
Check for warnings in a bunch of the linker invocations, and add one with both -static-libgcc and -static on the commandline. Fix a warning in the latter case due to a backwards short circuiting || operator in the driver. No real functionality changed here, just allows the driver to properly consume -static-libgcc when -static is also specified. llvm-svn: 176429
2013-03-04 10:07:55 +08:00
// CHECK-LD-32-NOT: warning:
Add initial support for applying the sysroot to library search paths. This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
2011-10-03 14:41:08 +08:00
// CHECK-LD-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-LD-32: "{{.*}}/usr/lib/gcc/i386-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
Teach the logic for locating an installed GCC about the system root. This requires fixing a latent bug -- if we used the default host triple instead of an autodetected triple to locate GCC's installation, we didn't go back and fix the GCC triple. Correct that with a pile of hacks. This entire routine needs a major refactoring which I'm saving for a subsequent commit. Essentially, the detection of the GCC triple should be hoisted into the same routine as we locate the GCC installation: the first is intrinsically tied to the latter. Then the routine will just return the triple and base directory. Also start to bring the rest of the library search path logic under test, including locating crtbegin.o. Still need to test the multilib and other behaviors, but there are also bugs in the way of that. llvm-svn: 140995
2011-10-03 16:02:58 +08:00
// CHECK-LD-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0"
Test that we include a GCC-triple-prefixed tree. While I don't know of any distros that use this, building a multilib GCC from mainline will install linker scripts here. llvm-svn: 140996
2011-10-03 16:09:02 +08:00
// CHECK-LD-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/lib"
Teach the logic for locating an installed GCC about the system root. This requires fixing a latent bug -- if we used the default host triple instead of an autodetected triple to locate GCC's installation, we didn't go back and fix the GCC triple. Correct that with a pile of hacks. This entire routine needs a major refactoring which I'm saving for a subsequent commit. Essentially, the detection of the GCC triple should be hoisted into the same routine as we locate the GCC installation: the first is intrinsically tied to the latter. Then the routine will just return the triple and base directory. Also start to bring the rest of the library search path logic under test, including locating crtbegin.o. Still need to test the multilib and other behaviors, but there are also bugs in the way of that. llvm-svn: 140995
2011-10-03 16:02:58 +08:00
// CHECK-LD-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../.."
// CHECK-LD-32: "-L[[SYSROOT]]/lib"
// CHECK-LD-32: "-L[[SYSROOT]]/usr/lib"
Add a test that ensures we get the basic multilib '-L' flags to 'ld' invocations on Linux. llvm-svn: 140909
2011-10-01 08:37:39 +08:00
//
Add initial support for applying the sysroot to library search paths. This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
2011-10-03 14:41:08 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-unknown-linux -rtlib=platform \
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="" \
Add initial support for applying the sysroot to library search paths. This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
2011-10-03 14:41:08 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
Add a test that ensures we get the basic multilib '-L' flags to 'ld' invocations on Linux. llvm-svn: 140909
2011-10-01 08:37:39 +08:00
// RUN: | FileCheck --check-prefix=CHECK-LD-64 %s
Check for warnings in a bunch of the linker invocations, and add one with both -static-libgcc and -static on the commandline. Fix a warning in the latter case due to a backwards short circuiting || operator in the driver. No real functionality changed here, just allows the driver to properly consume -static-libgcc when -static is also specified. llvm-svn: 176429
2013-03-04 10:07:55 +08:00
// CHECK-LD-64-NOT: warning:
Add initial support for applying the sysroot to library search paths. This is still very much a WIP, but sysroot was completely broken before this so we are moving closer to correctness. The crux of this is that 'ld' (on Linux, the only place I'm touching here) doesn't apply the sysroot to any flags given to it. Instead, the driver must translate all the paths it adds to the link step with the system root. This is easily observed by building a GCC that supports sysroot, and checking its driver output. This patch just fixes the non-multilib library search paths. We should also use this in many other places, but first things first. This also allows us to make the Linux 'ld' test independent of the host system. This in turn will allow me to check in test tree configurations based on various different distro's configuration. Again, WIP. llvm-svn: 140990
2011-10-03 14:41:08 +08:00
// CHECK-LD-64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// CHECK-LD-64: "--eh-frame-hdr"
// CHECK-LD-64: "-m" "elf_x86_64"
// CHECK-LD-64: "-dynamic-linker"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-LD-64: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
Teach the logic for locating an installed GCC about the system root. This requires fixing a latent bug -- if we used the default host triple instead of an autodetected triple to locate GCC's installation, we didn't go back and fix the GCC triple. Correct that with a pile of hacks. This entire routine needs a major refactoring which I'm saving for a subsequent commit. Essentially, the detection of the GCC triple should be hoisted into the same routine as we locate the GCC installation: the first is intrinsically tied to the latter. Then the routine will just return the triple and base directory. Also start to bring the rest of the library search path logic under test, including locating crtbegin.o. Still need to test the multilib and other behaviors, but there are also bugs in the way of that. llvm-svn: 140995
2011-10-03 16:02:58 +08:00
// CHECK-LD-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
Test that we include a GCC-triple-prefixed tree. While I don't know of any distros that use this, building a multilib GCC from mainline will install linker scripts here. llvm-svn: 140996
2011-10-03 16:09:02 +08:00
// CHECK-LD-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
Teach the logic for locating an installed GCC about the system root. This requires fixing a latent bug -- if we used the default host triple instead of an autodetected triple to locate GCC's installation, we didn't go back and fix the GCC triple. Correct that with a pile of hacks. This entire routine needs a major refactoring which I'm saving for a subsequent commit. Essentially, the detection of the GCC triple should be hoisted into the same routine as we locate the GCC installation: the first is intrinsically tied to the latter. Then the routine will just return the triple and base directory. Also start to bring the rest of the library search path logic under test, including locating crtbegin.o. Still need to test the multilib and other behaviors, but there are also bugs in the way of that. llvm-svn: 140995
2011-10-03 16:02:58 +08:00
// CHECK-LD-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-LD-64: "-L[[SYSROOT]]/lib"
// CHECK-LD-64: "-L[[SYSROOT]]/usr/lib"
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// CHECK-LD-64: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
// CHECK-LD-64: "-lc"
// CHECK-LD-64: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-unknown-linux-gnux32 -rtlib=platform \
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: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-LD-X32 %s
// CHECK-LD-X32-NOT: warning:
// CHECK-LD-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-X32: "--eh-frame-hdr"
// CHECK-LD-X32: "-m" "elf32_x86_64"
// CHECK-LD-X32: "-dynamic-linker"
// CHECK-LD-X32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
// CHECK-LD-X32: "-lc"
// CHECK-LD-X32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=x86_64-unknown-linux \
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="" \
Add EXPERIMENTAL --rtlib=compiler-rt to GNU Clang This commit is not strictly correct nor accounts for all uses (shared objects, for example), but it allows one to test the compiler-rt library on GNU targets. Using this patch to run the test-suite has already shown me problems on ARM. Since this is a Darwin-only flag, nobody is using it, so it shouldn't be a problem. I will need extension to deal with the shared cases, but since we're not compiling libclang_rt.so, that's not yet applicable. Many other problems will have to be fixed first in compiler-rt (such as removing the 'arch' name from it and making it trully multi-arch, moving it to the default lib directory, make both .a and .so variants, etc). llvm-svn: 201307
2014-02-13 18:01:16 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: --rtlib=compiler-rt \
// RUN: | FileCheck --check-prefix=CHECK-LD-RT %s
// CHECK-LD-RT-NOT: warning:
// CHECK-LD-RT: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-RT: "--eh-frame-hdr"
// CHECK-LD-RT: "-m" "elf_x86_64"
// CHECK-LD-RT: "-dynamic-linker"
// CHECK-LD-RT: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
// CHECK-LD-RT: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-LD-RT: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-LD-RT: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-LD-RT: "-L[[SYSROOT]]/lib"
// CHECK-LD-RT: "-L[[SYSROOT]]/usr/lib"
[Compiler-RT] Remove dependency on libgcc_s/eh Currently, for --rtlib=compiler-rt on GNU systems, we're assuming that one has libgcc_s and libgcc_eh as low-level libraries, which when used in conjunction with -lunwind or -lc++abi, breaks that assumption. My original fix was wrong, and this patch reverts it to prepare for a new flag to choose the unwinder/C++ libraries. For the time being, people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any combination they need explicitly. llvm-svn: 243025
2015-07-24 01:24:41 +08:00
// CHECK-LD-RT: libclang_rt.builtins-x86_64.a"
Add EXPERIMENTAL --rtlib=compiler-rt to GNU Clang This commit is not strictly correct nor accounts for all uses (shared objects, for example), but it allows one to test the compiler-rt library on GNU targets. Using this patch to run the test-suite has already shown me problems on ARM. Since this is a Darwin-only flag, nobody is using it, so it shouldn't be a problem. I will need extension to deal with the shared cases, but since we're not compiling libclang_rt.so, that's not yet applicable. Many other problems will have to be fixed first in compiler-rt (such as removing the 'arch' name from it and making it trully multi-arch, moving it to the default lib directory, make both .a and .so variants, etc). llvm-svn: 201307
2014-02-13 18:01:16 +08:00
// CHECK-LD-RT: "-lc"
[Compiler-RT] Remove dependency on libgcc_s/eh Currently, for --rtlib=compiler-rt on GNU systems, we're assuming that one has libgcc_s and libgcc_eh as low-level libraries, which when used in conjunction with -lunwind or -lc++abi, breaks that assumption. My original fix was wrong, and this patch reverts it to prepare for a new flag to choose the unwinder/C++ libraries. For the time being, people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any combination they need explicitly. llvm-svn: 243025
2015-07-24 01:24:41 +08:00
// CHECK-LD-RT: libclang_rt.builtins-x86_64.a"
[clang] Use -android environment for all compiler-rt libs. Summary: This was already done for the sanitizers, but it needs to be done for the profile and builtin libs as well. Reviewers: srhines, timmurray, eugenis, samsonov Reviewed By: samsonov Subscribers: compnerd, cfe-commits Differential Revision: http://reviews.llvm.org/D7187 llvm-svn: 227392
2015-01-29 07:23:36 +08:00
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-androideabi \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: --rtlib=compiler-rt \
// RUN: | FileCheck --check-prefix=CHECK-LD-RT-ANDROID %s
// CHECK-LD-RT-ANDROID-NOT: warning:
// CHECK-LD-RT-ANDROID: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-RT-ANDROID: "--eh-frame-hdr"
// CHECK-LD-RT-ANDROID: "-m" "armelf_linux_eabi"
// CHECK-LD-RT-ANDROID: "-dynamic-linker"
[Compiler-RT] Remove dependency on libgcc_s/eh Currently, for --rtlib=compiler-rt on GNU systems, we're assuming that one has libgcc_s and libgcc_eh as low-level libraries, which when used in conjunction with -lunwind or -lc++abi, breaks that assumption. My original fix was wrong, and this patch reverts it to prepare for a new flag to choose the unwinder/C++ libraries. For the time being, people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any combination they need explicitly. llvm-svn: 243025
2015-07-24 01:24:41 +08:00
// CHECK-LD-RT-ANDROID: libclang_rt.builtins-arm-android.a"
[clang] Use -android environment for all compiler-rt libs. Summary: This was already done for the sanitizers, but it needs to be done for the profile and builtin libs as well. Reviewers: srhines, timmurray, eugenis, samsonov Reviewed By: samsonov Subscribers: compnerd, cfe-commits Differential Revision: http://reviews.llvm.org/D7187 llvm-svn: 227392
2015-01-29 07:23:36 +08:00
// CHECK-LD-RT-ANDROID: "-lc"
[Compiler-RT] Remove dependency on libgcc_s/eh Currently, for --rtlib=compiler-rt on GNU systems, we're assuming that one has libgcc_s and libgcc_eh as low-level libraries, which when used in conjunction with -lunwind or -lc++abi, breaks that assumption. My original fix was wrong, and this patch reverts it to prepare for a new flag to choose the unwinder/C++ libraries. For the time being, people can use "-lgcc_s -lgcc_eh" or "-lunwind -lc++abi" or any combination they need explicitly. llvm-svn: 243025
2015-07-24 01:24:41 +08:00
// CHECK-LD-RT-ANDROID: libclang_rt.builtins-arm-android.a"
Add EXPERIMENTAL --rtlib=compiler-rt to GNU Clang This commit is not strictly correct nor accounts for all uses (shared objects, for example), but it allows one to test the compiler-rt library on GNU targets. Using this patch to run the test-suite has already shown me problems on ARM. Since this is a Darwin-only flag, nobody is using it, so it shouldn't be a problem. I will need extension to deal with the shared cases, but since we're not compiling libclang_rt.so, that's not yet applicable. Many other problems will have to be fixed first in compiler-rt (such as removing the 'arch' name from it and making it trully multi-arch, moving it to the default lib directory, make both .a and .so variants, etc). llvm-svn: 201307
2014-02-13 18:01:16 +08:00
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-unknown-linux -rtlib=platform \
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="" \
Add EXPERIMENTAL --rtlib=compiler-rt to GNU Clang This commit is not strictly correct nor accounts for all uses (shared objects, for example), but it allows one to test the compiler-rt library on GNU targets. Using this patch to run the test-suite has already shown me problems on ARM. Since this is a Darwin-only flag, nobody is using it, so it shouldn't be a problem. I will need extension to deal with the shared cases, but since we're not compiling libclang_rt.so, that's not yet applicable. Many other problems will have to be fixed first in compiler-rt (such as removing the 'arch' name from it and making it trully multi-arch, moving it to the default lib directory, make both .a and .so variants, etc). llvm-svn: 201307
2014-02-13 18:01:16 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: --rtlib=libgcc \
// RUN: | FileCheck --check-prefix=CHECK-LD-GCC %s
// CHECK-LD-GCC-NOT: warning:
// CHECK-LD-GCC: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-GCC: "--eh-frame-hdr"
// CHECK-LD-GCC: "-m" "elf_x86_64"
// CHECK-LD-GCC: "-dynamic-linker"
// CHECK-LD-GCC: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
// CHECK-LD-GCC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-LD-GCC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-LD-GCC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-LD-GCC: "-L[[SYSROOT]]/lib"
// CHECK-LD-GCC: "-L[[SYSROOT]]/usr/lib"
Fix CHECK directives that weren't checking. llvm-svn: 246492
2015-09-01 05:48:52 +08:00
// CHECK-LD-GCC: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
Add EXPERIMENTAL --rtlib=compiler-rt to GNU Clang This commit is not strictly correct nor accounts for all uses (shared objects, for example), but it allows one to test the compiler-rt library on GNU targets. Using this patch to run the test-suite has already shown me problems on ARM. Since this is a Darwin-only flag, nobody is using it, so it shouldn't be a problem. I will need extension to deal with the shared cases, but since we're not compiling libclang_rt.so, that's not yet applicable. Many other problems will have to be fixed first in compiler-rt (such as removing the 'arch' name from it and making it trully multi-arch, moving it to the default lib directory, make both .a and .so variants, etc). llvm-svn: 201307
2014-02-13 18:01:16 +08:00
// CHECK-LD-GCC: "-lc"
// CHECK-LD-GCC: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-unknown-linux -rtlib=platform \
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// RUN: -static-libgcc \
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="" \
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-LD-64-STATIC-LIBGCC %s
Check for warnings in a bunch of the linker invocations, and add one with both -static-libgcc and -static on the commandline. Fix a warning in the latter case due to a backwards short circuiting || operator in the driver. No real functionality changed here, just allows the driver to properly consume -static-libgcc when -static is also specified. llvm-svn: 176429
2013-03-04 10:07:55 +08:00
// CHECK-LD-64-STATIC-LIBGCC-NOT: warning:
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// CHECK-LD-64-STATIC-LIBGCC: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-64-STATIC-LIBGCC: "--eh-frame-hdr"
// CHECK-LD-64-STATIC-LIBGCC: "-m" "elf_x86_64"
// CHECK-LD-64-STATIC-LIBGCC: "-dynamic-linker"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-LD-64-STATIC-LIBGCC: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// CHECK-LD-64-STATIC-LIBGCC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-LD-64-STATIC-LIBGCC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-LD-64-STATIC-LIBGCC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-LD-64-STATIC-LIBGCC: "-L[[SYSROOT]]/lib"
// CHECK-LD-64-STATIC-LIBGCC: "-L[[SYSROOT]]/usr/lib"
// CHECK-LD-64-STATIC-LIBGCC: "-lgcc" "-lgcc_eh"
// CHECK-LD-64-STATIC-LIBGCC: "-lc"
// CHECK-LD-64-STATIC-LIBGCC: "-lgcc" "-lgcc_eh"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-unknown-linux -rtlib=platform \
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// RUN: -static \
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="" \
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-LD-64-STATIC %s
Check for warnings in a bunch of the linker invocations, and add one with both -static-libgcc and -static on the commandline. Fix a warning in the latter case due to a backwards short circuiting || operator in the driver. No real functionality changed here, just allows the driver to properly consume -static-libgcc when -static is also specified. llvm-svn: 176429
2013-03-04 10:07:55 +08:00
// CHECK-LD-64-STATIC-NOT: warning:
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// CHECK-LD-64-STATIC: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-64-STATIC-NOT: "--eh-frame-hdr"
// CHECK-LD-64-STATIC: "-m" "elf_x86_64"
// CHECK-LD-64-STATIC-NOT: "-dynamic-linker"
// CHECK-LD-64-STATIC: "-static"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-LD-64-STATIC: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbeginT.o"
Beef up the testing of our 'ld' invocation on linux to cover static linking. About to fix a bug here and there was no good test case. llvm-svn: 176427
2013-03-04 09:27:49 +08:00
// CHECK-LD-64-STATIC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-LD-64-STATIC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-LD-64-STATIC: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-LD-64-STATIC: "-L[[SYSROOT]]/lib"
// CHECK-LD-64-STATIC: "-L[[SYSROOT]]/usr/lib"
// CHECK-LD-64-STATIC: "--start-group" "-lgcc" "-lgcc_eh" "-lc" "--end-group"
Enable generic multilib support on 32bit hosts. Previously this was only enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
2011-10-03 17:00:50 +08:00
//
Check for warnings in a bunch of the linker invocations, and add one with both -static-libgcc and -static on the commandline. Fix a warning in the latter case due to a backwards short circuiting || operator in the driver. No real functionality changed here, just allows the driver to properly consume -static-libgcc when -static is also specified. llvm-svn: 176429
2013-03-04 10:07:55 +08:00
// Check that flags can be combined. The -static dominates.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-unknown-linux -rtlib=platform \
Check for warnings in a bunch of the linker invocations, and add one with both -static-libgcc and -static on the commandline. Fix a warning in the latter case due to a backwards short circuiting || operator in the driver. No real functionality changed here, just allows the driver to properly consume -static-libgcc when -static is also specified. llvm-svn: 176429
2013-03-04 10:07:55 +08:00
// RUN: -static-libgcc -static \
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="" \
Check for warnings in a bunch of the linker invocations, and add one with both -static-libgcc and -static on the commandline. Fix a warning in the latter case due to a backwards short circuiting || operator in the driver. No real functionality changed here, just allows the driver to properly consume -static-libgcc when -static is also specified. llvm-svn: 176429
2013-03-04 10:07:55 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-LD-64-STATIC %s
//
Enable generic multilib support on 32bit hosts. Previously this was only enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
2011-10-03 17:00:50 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux -m32 \
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="" \
Enable generic multilib support on 32bit hosts. Previously this was only enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
2011-10-03 17:00:50 +08:00
// RUN: --sysroot=%S/Inputs/multilib_32bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-32-TO-32 %s
// CHECK-32-TO-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-32-TO-32: "{{.*}}/usr/lib/gcc/i386-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
Enable generic multilib support on 32bit hosts. Previously this was only enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
2011-10-03 17:00:50 +08:00
// CHECK-32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0"
Revert "Support cross linking to arm on ubuntu." This reverts commit r193528 (and fixes). It broke Chandler's setup. llvm-svn: 193554
2013-10-29 07:14:34 +08:00
// CHECK-32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/lib/../lib32"
// CHECK-32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../lib32"
// CHECK-32-TO-32: "-L[[SYSROOT]]/lib/../lib32"
// CHECK-32-TO-32: "-L[[SYSROOT]]/usr/lib/../lib32"
Enable generic multilib support on 32bit hosts. Previously this was only enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
2011-10-03 17:00:50 +08:00
// CHECK-32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/lib"
// CHECK-32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../.."
// CHECK-32-TO-32: "-L[[SYSROOT]]/lib"
// CHECK-32-TO-32: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux -m64 \
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="" \
Enable generic multilib support on 32bit hosts. Previously this was only enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
2011-10-03 17:00:50 +08:00
// RUN: --sysroot=%S/Inputs/multilib_32bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-32-TO-64 %s
// CHECK-32-TO-64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-32-TO-64: "{{.*}}/usr/lib/gcc/i386-unknown-linux/4.6.0/64{{/|\\\\}}crtbegin.o"
Enable generic multilib support on 32bit hosts. Previously this was only enabled for debian hosts, which is quite odd. I think all restriction on when Clang attempts to use a multilib installation should go away. Clang is fundamentally a cross compiler. It behaves more like GCC when built as a cross compiler, and so it should just use multilib installs when they are present on the system. However, there is a very specific exemption for Exherbo, which I can't test on, so I'm leaving that in place. With this, check in a generic test tree for multilib on a 32-bit host. This stubs out many directories that most distributions don't use but that uptsream GCC supports. This is intended to be an agnostic test that the driver behaves properly compared with the GCC driver it aims for compatibility with. Also, fix a bug in the driver that this testing exposed (see!) where it was incorrectly testing the target architecture rather than the host architecture. If anyone is having trouble with the tree-structure stubs I'm creating to test this, let me know and I can revisit the design. I chose this over (for example) a tar-ball in order to make tests run faster at the small, hopefully amortized VCS cost. llvm-svn: 140999
2011-10-03 17:00:50 +08:00
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/64"
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/lib/../lib64"
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../lib64"
// CHECK-32-TO-64: "-L[[SYSROOT]]/lib/../lib64"
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib/../lib64"
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0"
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../../../i386-unknown-linux/lib"
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/i386-unknown-linux/4.6.0/../../.."
// CHECK-32-TO-64: "-L[[SYSROOT]]/lib"
// CHECK-32-TO-64: "-L[[SYSROOT]]/usr/lib"
Test a multilib setup on a 64-bit host. This is the far more common configuration, although the test still stubs out more directories than are necessary or common in order to exercise all of the lookup paths observed with upstream GCC. This finishes testing the distribution-independent and GCC-installation-independent parts of the library path search logic. More testing is still needed for the triple detection, GCC-installation detection, and handling distributions with unusual configurations. llvm-svn: 141000
2011-10-03 17:08:26 +08:00
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=x86_64-unknown-linux -m64 \
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="" \
Test a multilib setup on a 64-bit host. This is the far more common configuration, although the test still stubs out more directories than are necessary or common in order to exercise all of the lookup paths observed with upstream GCC. This finishes testing the distribution-independent and GCC-installation-independent parts of the library path search logic. More testing is still needed for the triple detection, GCC-installation detection, and handling distributions with unusual configurations. llvm-svn: 141000
2011-10-03 17:08:26 +08:00
// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-64-TO-64 %s
// CHECK-64-TO-64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-64-TO-64: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
Test a multilib setup on a 64-bit host. This is the far more common configuration, although the test still stubs out more directories than are necessary or common in order to exercise all of the lookup paths observed with upstream GCC. This finishes testing the distribution-independent and GCC-installation-independent parts of the library path search logic. More testing is still needed for the triple detection, GCC-installation detection, and handling distributions with unusual configurations. llvm-svn: 141000
2011-10-03 17:08:26 +08:00
// CHECK-64-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
Revert "Support cross linking to arm on ubuntu." This reverts commit r193528 (and fixes). It broke Chandler's setup. llvm-svn: 193554
2013-10-29 07:14:34 +08:00
// CHECK-64-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib/../lib64"
// CHECK-64-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../lib64"
// CHECK-64-TO-64: "-L[[SYSROOT]]/lib/../lib64"
// CHECK-64-TO-64: "-L[[SYSROOT]]/usr/lib/../lib64"
Test a multilib setup on a 64-bit host. This is the far more common configuration, although the test still stubs out more directories than are necessary or common in order to exercise all of the lookup paths observed with upstream GCC. This finishes testing the distribution-independent and GCC-installation-independent parts of the library path search logic. More testing is still needed for the triple detection, GCC-installation detection, and handling distributions with unusual configurations. llvm-svn: 141000
2011-10-03 17:08:26 +08:00
// CHECK-64-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-64-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-64-TO-64: "-L[[SYSROOT]]/lib"
// CHECK-64-TO-64: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=x86_64-unknown-linux -m32 \
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="" \
Test a multilib setup on a 64-bit host. This is the far more common configuration, although the test still stubs out more directories than are necessary or common in order to exercise all of the lookup paths observed with upstream GCC. This finishes testing the distribution-independent and GCC-installation-independent parts of the library path search logic. More testing is still needed for the triple detection, GCC-installation detection, and handling distributions with unusual configurations. llvm-svn: 141000
2011-10-03 17:08:26 +08:00
// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-64-TO-32 %s
// CHECK-64-TO-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-64-TO-32: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32{{/|\\\\}}crtbegin.o"
Test a multilib setup on a 64-bit host. This is the far more common configuration, although the test still stubs out more directories than are necessary or common in order to exercise all of the lookup paths observed with upstream GCC. This finishes testing the distribution-independent and GCC-installation-independent parts of the library path search logic. More testing is still needed for the triple detection, GCC-installation detection, and handling distributions with unusual configurations. llvm-svn: 141000
2011-10-03 17:08:26 +08:00
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32"
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib/../lib32"
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../lib32"
// CHECK-64-TO-32: "-L[[SYSROOT]]/lib/../lib32"
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib/../lib32"
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-64-TO-32: "-L[[SYSROOT]]/lib"
// CHECK-64-TO-32: "-L[[SYSROOT]]/usr/lib"
Implement the feature I was originally driving toward when I started this saga. Teach the driver to detect a GCC installed along side Clang using the existing InstalledDir support in the Clang driver. This makes a lot of Clang's behavior more automatic when it is installed along side GCC. Also include the first test cases (more to come, honest) which test both the install directory behavior, and the version sorting behavior to show that we're actually searching for the best candidate GCC installation now. llvm-svn: 141145
2011-10-05 09:01:57 +08:00
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
[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: --target=x86_64-unknown-linux-gnux32 \
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: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-X32 %s
// CHECK-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-X32: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0/x32{{/|\\\\}}crtbegin.o"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/x32"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib/../libx32"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../libx32"
// CHECK-X32: "-L[[SYSROOT]]/lib/../libx32"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib/../libx32"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-X32: "-L[[SYSROOT]]/lib"
// CHECK-X32: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
[PATCH] [x32] Introduce -mx32 flag enforcing x32 mode for other triplets. By Pavel Chupin (@pavel.v.chupin). -mx32 flag setup target environment to GNUX32 and can be used for other 32/64-bit triplets (i386-unknown-linux, x86_64-unknown-linux) to turn on x32 mode. Compatible with GCC -mx32 flag. Differential Revision: http://reviews.llvm.org/D4470 llvm-svn: 212817
2014-07-11 22:28:45 +08:00
// RUN: --target=x86_64-unknown-linux -mx32 \
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="" \
[PATCH] [x32] Introduce -mx32 flag enforcing x32 mode for other triplets. By Pavel Chupin (@pavel.v.chupin). -mx32 flag setup target environment to GNUX32 and can be used for other 32/64-bit triplets (i386-unknown-linux, x86_64-unknown-linux) to turn on x32 mode. Compatible with GCC -mx32 flag. Differential Revision: http://reviews.llvm.org/D4470 llvm-svn: 212817
2014-07-11 22:28:45 +08:00
// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-64-TO-X32 %s
// CHECK-64-TO-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-64-TO-X32: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0/x32{{/|\\\\}}crtbegin.o"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/x32"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib/../libx32"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../libx32"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/lib/../libx32"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib/../libx32"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-64-TO-X32: "-L[[SYSROOT]]/lib"
// CHECK-64-TO-X32: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=i386-unknown-linux -mx32 \
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="" \
[PATCH] [x32] Introduce -mx32 flag enforcing x32 mode for other triplets. By Pavel Chupin (@pavel.v.chupin). -mx32 flag setup target environment to GNUX32 and can be used for other 32/64-bit triplets (i386-unknown-linux, x86_64-unknown-linux) to turn on x32 mode. Compatible with GCC -mx32 flag. Differential Revision: http://reviews.llvm.org/D4470 llvm-svn: 212817
2014-07-11 22:28:45 +08:00
// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-32-TO-X32 %s
// CHECK-32-TO-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-32-TO-X32: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0/x32{{/|\\\\}}crtbegin.o"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/x32"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib/../libx32"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../libx32"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/lib/../libx32"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib/../libx32"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-32-TO-X32: "-L[[SYSROOT]]/lib"
// CHECK-32-TO-X32: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
[x32] Handle -m64/-m32 switches by Driver in x32 mode Summary: Adding remaining 2 cases handling: * from x32 to 32 via -m32 * from x32 to 64 via -m64 Test Plan: linux-ld test updated Reviewers: chandlerc, atanasyan Subscribers: cfe-commits, zinovy.nis Differential Revision: http://reviews.llvm.org/D4930 llvm-svn: 215899
2014-08-18 23:38:38 +08:00
// RUN: --target=x86_64-unknown-linux-gnux32 -m64 \
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] Handle -m64/-m32 switches by Driver in x32 mode Summary: Adding remaining 2 cases handling: * from x32 to 32 via -m32 * from x32 to 64 via -m64 Test Plan: linux-ld test updated Reviewers: chandlerc, atanasyan Subscribers: cfe-commits, zinovy.nis Differential Revision: http://reviews.llvm.org/D4930 llvm-svn: 215899
2014-08-18 23:38:38 +08:00
// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-X32-TO-64 %s
// CHECK-X32-TO-64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-X32-TO-64: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib/../lib64"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../lib64"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/lib/../lib64"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/usr/lib/../lib64"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-X32-TO-64: "-L[[SYSROOT]]/lib"
// CHECK-X32-TO-64: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnux32 -m32 \
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] Handle -m64/-m32 switches by Driver in x32 mode Summary: Adding remaining 2 cases handling: * from x32 to 32 via -m32 * from x32 to 64 via -m64 Test Plan: linux-ld test updated Reviewers: chandlerc, atanasyan Subscribers: cfe-commits, zinovy.nis Differential Revision: http://reviews.llvm.org/D4930 llvm-svn: 215899
2014-08-18 23:38:38 +08:00
// RUN: --sysroot=%S/Inputs/multilib_64bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-X32-TO-32 %s
// CHECK-X32-TO-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-X32-TO-32: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32{{/|\\\\}}crtbegin.o"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib/../lib32"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../lib32"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/lib/../lib32"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib/../lib32"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../../../x86_64-unknown-linux/lib"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0/../../.."
// CHECK-X32-TO-32: "-L[[SYSROOT]]/lib"
// CHECK-X32-TO-32: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=x86_64-unknown-linux -m32 \
// RUN: --gcc-toolchain=%S/Inputs/multilib_64bit_linux_tree/usr \
Fix using Clang as a cross compiler installed on a host machine and not inside of a sysroot targeting a system+sysroot which is "similar" or "compatible" with the host system. This shows up when trying to build system images on largely compatible hardware as-if fully cross compiled. The problem is that previously we *perfectly* mimiced GCC here, and it turns out GCC has a bug that no one has really stumbled across. GCC will try to look in thy system prefix ('/usr/local' f.ex.) into which it is instaled to find libraries installed along side GCC that should be preferred to the base system libraries ('/usr' f.ex.). This seems not unreasonable, but it has a very unfortunate consequence when combined with a '--sysroot' which does *not* contain the GCC installation we're using to complete the toolchain. That results in some of the host system's library directories being searched during the link. Now, it so happens that most folks doing stuff like this use '--with-sysroot' and '--disable-multilib' when configuring GCC. Even better, they're usually not cross-compiling to a target that is similar to the host. As a result, searching the host for libraries doesn't really matter -- most of the time weird directories get appended that don't exist (no arm triple lib directory, etc). Even if you're cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling multilib makes it less likely that you'll actually find viable libraries on the host. But that's just luck. We shouldn't rely on this, and this patch disables looking in the system prefix containing the GCC installation if that system prefix is *outside* of the sysroot. For empty sysroots, this has no effect. Similarly, when using the GCC *inside* of the sysroot, we still track wherever it is installed within the sysroot and look there for libraries. But now we can use a cross compiler GCC installation outside the system root, and only look for the crtbegin.o in the GCC installation, and look for all the other libraries inside the system root. This should fix PR12478, allowing Clang to be used when building a ChromiumOS image without polluting the image with libraries from the host system. llvm-svn: 154176
2012-04-07 00:32:06 +08:00
// RUN: --sysroot=%S/Inputs/multilib_32bit_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-64-TO-32-SYSROOT %s
// CHECK-64-TO-32-SYSROOT: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-64-TO-32-SYSROOT: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32{{/|\\\\}}crtbegin.o"
Fix using Clang as a cross compiler installed on a host machine and not inside of a sysroot targeting a system+sysroot which is "similar" or "compatible" with the host system. This shows up when trying to build system images on largely compatible hardware as-if fully cross compiled. The problem is that previously we *perfectly* mimiced GCC here, and it turns out GCC has a bug that no one has really stumbled across. GCC will try to look in thy system prefix ('/usr/local' f.ex.) into which it is instaled to find libraries installed along side GCC that should be preferred to the base system libraries ('/usr' f.ex.). This seems not unreasonable, but it has a very unfortunate consequence when combined with a '--sysroot' which does *not* contain the GCC installation we're using to complete the toolchain. That results in some of the host system's library directories being searched during the link. Now, it so happens that most folks doing stuff like this use '--with-sysroot' and '--disable-multilib' when configuring GCC. Even better, they're usually not cross-compiling to a target that is similar to the host. As a result, searching the host for libraries doesn't really matter -- most of the time weird directories get appended that don't exist (no arm triple lib directory, etc). Even if you're cross-compiling from 32-bit to 64-bit x86 or vice-versa, disabling multilib makes it less likely that you'll actually find viable libraries on the host. But that's just luck. We shouldn't rely on this, and this patch disables looking in the system prefix containing the GCC installation if that system prefix is *outside* of the sysroot. For empty sysroots, this has no effect. Similarly, when using the GCC *inside* of the sysroot, we still track wherever it is installed within the sysroot and look there for libraries. But now we can use a cross compiler GCC installation outside the system root, and only look for the crtbegin.o in the GCC installation, and look for all the other libraries inside the system root. This should fix PR12478, allowing Clang to be used when building a ChromiumOS image without polluting the image with libraries from the host system. llvm-svn: 154176
2012-04-07 00:32:06 +08:00
// CHECK-64-TO-32-SYSROOT: "-L{{[^"]*}}/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0/32"
// CHECK-64-TO-32-SYSROOT: "-L[[SYSROOT]]/lib/../lib32"
// CHECK-64-TO-32-SYSROOT: "-L[[SYSROOT]]/usr/lib/../lib32"
// CHECK-64-TO-32-SYSROOT: "-L{{[^"]*}}/Inputs/multilib_64bit_linux_tree/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
// CHECK-64-TO-32-SYSROOT: "-L[[SYSROOT]]/lib"
// CHECK-64-TO-32-SYSROOT: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux -m32 \
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// RUN: -ccc-install-dir %S/Inputs/fake_install_tree/bin \
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="" \
Implement the feature I was originally driving toward when I started this saga. Teach the driver to detect a GCC installed along side Clang using the existing InstalledDir support in the Clang driver. This makes a lot of Clang's behavior more automatic when it is installed along side GCC. Also include the first test cases (more to come, honest) which test both the install directory behavior, and the version sorting behavior to show that we're actually searching for the best candidate GCC installation now. llvm-svn: 141145
2011-10-05 09:01:57 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-INSTALL-DIR-32 %s
// CHECK-INSTALL-DIR-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-INSTALL-DIR-32: "{{.*}}/Inputs/fake_install_tree/bin/../lib/gcc/i386-unknown-linux/4.7.0{{/|\\\\}}crtbegin.o"
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// CHECK-INSTALL-DIR-32: "-L{{.*}}/Inputs/fake_install_tree/bin/../lib/gcc/i386-unknown-linux/4.7.0"
Implement the feature I was originally driving toward when I started this saga. Teach the driver to detect a GCC installed along side Clang using the existing InstalledDir support in the Clang driver. This makes a lot of Clang's behavior more automatic when it is installed along side GCC. Also include the first test cases (more to come, honest) which test both the install directory behavior, and the version sorting behavior to show that we're actually searching for the best candidate GCC installation now. llvm-svn: 141145
2011-10-05 09:01:57 +08:00
//
// Check that with 64-bit builds, we don't actually use the install directory
// as its version of GCC is lower than our sysrooted version.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=x86_64-unknown-linux -m64 \
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// RUN: -ccc-install-dir %S/Inputs/fake_install_tree/bin \
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="" \
Implement the feature I was originally driving toward when I started this saga. Teach the driver to detect a GCC installed along side Clang using the existing InstalledDir support in the Clang driver. This makes a lot of Clang's behavior more automatic when it is installed along side GCC. Also include the first test cases (more to come, honest) which test both the install directory behavior, and the version sorting behavior to show that we're actually searching for the best candidate GCC installation now. llvm-svn: 141145
2011-10-05 09:01:57 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-INSTALL-DIR-64 %s
// CHECK-INSTALL-DIR-64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-INSTALL-DIR-64: "{{.*}}/usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtbegin.o"
Implement the feature I was originally driving toward when I started this saga. Teach the driver to detect a GCC installed along side Clang using the existing InstalledDir support in the Clang driver. This makes a lot of Clang's behavior more automatic when it is installed along side GCC. Also include the first test cases (more to come, honest) which test both the install directory behavior, and the version sorting behavior to show that we're actually searching for the best candidate GCC installation now. llvm-svn: 141145
2011-10-05 09:01:57 +08:00
// CHECK-INSTALL-DIR-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-unknown-linux/4.6.0"
Teach Clang to cope with GCC installations that have unusual patch "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159
2011-10-05 11:09:51 +08:00
//
// Check that we support unusual patch version formats, including missing that
// component.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux -m32 \
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// RUN: -ccc-install-dir %S/Inputs/gcc_version_parsing1/bin \
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 Clang to cope with GCC installations that have unusual patch "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159
2011-10-05 11:09:51 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-GCC-VERSION1 %s
// CHECK-GCC-VERSION1: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-GCC-VERSION1: "{{.*}}/Inputs/gcc_version_parsing1/bin/../lib/gcc/i386-unknown-linux/4.7{{/|\\\\}}crtbegin.o"
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// CHECK-GCC-VERSION1: "-L{{.*}}/Inputs/gcc_version_parsing1/bin/../lib/gcc/i386-unknown-linux/4.7"
Teach Clang to cope with GCC installations that have unusual patch "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159
2011-10-05 11:09:51 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux -m32 \
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// RUN: -ccc-install-dir %S/Inputs/gcc_version_parsing2/bin \
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 Clang to cope with GCC installations that have unusual patch "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159
2011-10-05 11:09:51 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-GCC-VERSION2 %s
// CHECK-GCC-VERSION2: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-GCC-VERSION2: "{{.*}}/Inputs/gcc_version_parsing2/bin/../lib/gcc/i386-unknown-linux/4.7.x{{/|\\\\}}crtbegin.o"
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// CHECK-GCC-VERSION2: "-L{{.*}}/Inputs/gcc_version_parsing2/bin/../lib/gcc/i386-unknown-linux/4.7.x"
Teach Clang to cope with GCC installations that have unusual patch "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159
2011-10-05 11:09:51 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux -m32 \
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// RUN: -ccc-install-dir %S/Inputs/gcc_version_parsing3/bin \
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 Clang to cope with GCC installations that have unusual patch "versions". Currently, these are just dropped on the floor, A concrete version number will always win out. llvm-svn: 141159
2011-10-05 11:09:51 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-GCC-VERSION3 %s
// CHECK-GCC-VERSION3: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-GCC-VERSION3: "{{.*}}/Inputs/gcc_version_parsing3/bin/../lib/gcc/i386-unknown-linux/4.7.99-rc5{{/|\\\\}}crtbegin.o"
Use the InstalledDir correctly, and test it correctly as well. =/ Should have noticed this previously, sorry. llvm-svn: 141167
2011-10-05 14:38:03 +08:00
// CHECK-GCC-VERSION3: "-L{{.*}}/Inputs/gcc_version_parsing3/bin/../lib/gcc/i386-unknown-linux/4.7.99-rc5"
Enhance the GCC version parsing and comparison logic to handle some more edge cases and have better behavior. Specifically, we should actually prefer the general '4.6' version string over the '4.6.1' string, as '4.6.2' should be able to replace it without breaking rpaths or any other place that these paths have been embedded. Debian-based distributions are already using a path structure with symlinks to achieve in-place upgrades for patch versions. Now our parsing reflects this and we select the shorter paths instead of the longer paths. A separate issue was that we would not parse a leading patch version number even in the presence of a suffix. The above change makes this more problematic as it would cause a suffix being added to make us treat the entire thing as patch-version-agnostic, which it isn't. This changes the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that the latter has *some* patch number information. Currently, we always bias toward the shorter and more canonical version strings. If it becomes important we can add more Debian like rules to produce sequences such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5', but I'm very doubtful this will ever matter or be desirable. I've made the tests for this logic a bit more interesting, and added some specific tests for logic that is now different. llvm-svn: 143841
2011-11-06 07:24:30 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux -m32 \
Enhance the GCC version parsing and comparison logic to handle some more edge cases and have better behavior. Specifically, we should actually prefer the general '4.6' version string over the '4.6.1' string, as '4.6.2' should be able to replace it without breaking rpaths or any other place that these paths have been embedded. Debian-based distributions are already using a path structure with symlinks to achieve in-place upgrades for patch versions. Now our parsing reflects this and we select the shorter paths instead of the longer paths. A separate issue was that we would not parse a leading patch version number even in the presence of a suffix. The above change makes this more problematic as it would cause a suffix being added to make us treat the entire thing as patch-version-agnostic, which it isn't. This changes the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that the latter has *some* patch number information. Currently, we always bias toward the shorter and more canonical version strings. If it becomes important we can add more Debian like rules to produce sequences such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5', but I'm very doubtful this will ever matter or be desirable. I've made the tests for this logic a bit more interesting, and added some specific tests for logic that is now different. llvm-svn: 143841
2011-11-06 07:24:30 +08:00
// RUN: -ccc-install-dir %S/Inputs/gcc_version_parsing4/bin \
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="" \
Enhance the GCC version parsing and comparison logic to handle some more edge cases and have better behavior. Specifically, we should actually prefer the general '4.6' version string over the '4.6.1' string, as '4.6.2' should be able to replace it without breaking rpaths or any other place that these paths have been embedded. Debian-based distributions are already using a path structure with symlinks to achieve in-place upgrades for patch versions. Now our parsing reflects this and we select the shorter paths instead of the longer paths. A separate issue was that we would not parse a leading patch version number even in the presence of a suffix. The above change makes this more problematic as it would cause a suffix being added to make us treat the entire thing as patch-version-agnostic, which it isn't. This changes the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that the latter has *some* patch number information. Currently, we always bias toward the shorter and more canonical version strings. If it becomes important we can add more Debian like rules to produce sequences such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5', but I'm very doubtful this will ever matter or be desirable. I've made the tests for this logic a bit more interesting, and added some specific tests for logic that is now different. llvm-svn: 143841
2011-11-06 07:24:30 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-GCC-VERSION4 %s
// CHECK-GCC-VERSION4: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-GCC-VERSION4: "{{.*}}/Inputs/gcc_version_parsing4/bin/../lib/gcc/i386-unknown-linux/4.7.99{{/|\\\\}}crtbegin.o"
Enhance the GCC version parsing and comparison logic to handle some more edge cases and have better behavior. Specifically, we should actually prefer the general '4.6' version string over the '4.6.1' string, as '4.6.2' should be able to replace it without breaking rpaths or any other place that these paths have been embedded. Debian-based distributions are already using a path structure with symlinks to achieve in-place upgrades for patch versions. Now our parsing reflects this and we select the shorter paths instead of the longer paths. A separate issue was that we would not parse a leading patch version number even in the presence of a suffix. The above change makes this more problematic as it would cause a suffix being added to make us treat the entire thing as patch-version-agnostic, which it isn't. This changes the logic to distinguish between '4.4.x' and 4.4.1-x', and retain that the latter has *some* patch number information. Currently, we always bias toward the shorter and more canonical version strings. If it becomes important we can add more Debian like rules to produce sequences such as '4.4.1b' > '4.4.1' > '4.4.1-rc3' > '4.4.1-rc2' > '4.4.1-pre5', but I'm very doubtful this will ever matter or be desirable. I've made the tests for this logic a bit more interesting, and added some specific tests for logic that is now different. llvm-svn: 143841
2011-11-06 07:24:30 +08:00
// CHECK-GCC-VERSION4: "-L{{.*}}/Inputs/gcc_version_parsing4/bin/../lib/gcc/i386-unknown-linux/4.7.99"
[Driver] Adapt Linux::GCCVersion::Parse to match GCC 5 installations Summary: Some GCC 5 installations store the libstdc++ includes and GCC-specific files in paths without the minor part of the version number, such as /usr/include/c++/5 /usr/lib64/gcc/x86_64-suse-linux/5 Reviewers: cfe-commits, thiagomacieira, jroelofs Subscribers: tinti, jroelofs Differential Revision: http://reviews.llvm.org/D14727 llvm-svn: 273012
2016-06-18 00:47:14 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=i386-unknown-linux -m32 \
// RUN: -ccc-install-dir %S/Inputs/gcc_version_parsing5/bin \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-GCC-VERSION5 %s
// CHECK-GCC-VERSION5: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-GCC-VERSION5: "{{.*}}/Inputs/gcc_version_parsing5/bin/../lib/gcc/i386-unknown-linux/5{{/|\\\\}}crtbegin.o"
// CHECK-GCC-VERSION5: "-L{{.*}}/Inputs/gcc_version_parsing5/bin/../lib/gcc/i386-unknown-linux/5"
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
//
Teach Clang to look in its installation libdir for libraries (such as libc++) when the installation is within the system root. This doesn't really help cross compiles much, but we don't (currently) have a great story around libc++, cross compiles, and who is responsible for building and/or installing the libraries. However, it handles the very common case of non-cross builds in a way entirely consistent with GCC, so I'm hopeful this won't really hose anyone. This is the second patch that I think should be backported to 3.4 to give folks an easy to checkout and install working Clang+libc++ toolchain. llvm-svn: 199769
2014-01-22 06:49:05 +08:00
// Test a simulated installation of libc++ on Linux, both through sysroot and
// the installation path of Clang.
// RUN: %clangxx -no-canonical-prefixes -x c++ %s -### -o %t.o 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_tree/usr/bin \
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 Clang to look in its installation libdir for libraries (such as libc++) when the installation is within the system root. This doesn't really help cross compiles much, but we don't (currently) have a great story around libc++, cross compiles, and who is responsible for building and/or installing the libraries. However, it handles the very common case of non-cross builds in a way entirely consistent with GCC, so I'm hopeful this won't really hose anyone. This is the second patch that I think should be backported to 3.4 to give folks an easy to checkout and install working Clang+libc++ toolchain. llvm-svn: 199769
2014-01-22 06:49:05 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
// 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"
// CHECK-BASIC-LIBCXX-SYSROOT: "--sysroot=[[SYSROOT]]"
// RUN: %clang -no-canonical-prefixes -x c++ %s -### -o %t.o 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_libcxx_tree/usr/bin \
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 Clang to look in its installation libdir for libraries (such as libc++) when the installation is within the system root. This doesn't really help cross compiles much, but we don't (currently) have a great story around libc++, cross compiles, and who is responsible for building and/or installing the libraries. However, it handles the very common case of non-cross builds in a way entirely consistent with GCC, so I'm hopeful this won't really hose anyone. This is the second patch that I think should be backported to 3.4 to give folks an easy to checkout and install working Clang+libc++ toolchain. llvm-svn: 199769
2014-01-22 06:49:05 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
// 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"
// CHECK-BASIC-LIBCXX-INSTALL: "--sysroot=[[SYSROOT]]"
// CHECK-BASIC-LIBCXX-INSTALL: "-L[[SYSROOT]]/usr/bin/../lib"
//
Much like we silence warnings about -flto in many cases to facilitate simplicity in build systems, silence '-stdlib=libc++' when linking. Even if we're not linking C++ code per-se, we may be passing this flag so that when we are linking C++ code we pick up the desired standard library. While most build systems already provide separate C and C++ compile flags, many conflate link flags. Sadly, CMake is among them causing this warning in a libc++ selfhost. llvm-svn: 231559
2015-03-07 18:01:29 +08:00
// Test that we can use -stdlib=libc++ in a build system even when it
// occasionally links C code instead of C++ code.
// RUN: %clang -no-canonical-prefixes -x c %s -### -o %t.o 2>&1 \
// RUN: -target x86_64-unknown-linux-gnu \
// RUN: -stdlib=libc++ \
// RUN: -ccc-install-dir %S/Inputs/basic_linux_libcxx_tree/usr/bin \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_linux_libcxx_tree \
// RUN: | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-C-LINK %s
// CHECK-BASIC-LIBCXX-C-LINK-NOT: warning:
// CHECK-BASIC-LIBCXX-C-LINK: "{{[^"]*}}clang{{[^"]*}}" "-cc1"
// CHECK-BASIC-LIBCXX-C-LINK: "-isysroot" "[[SYSROOT:[^"]+]]"
// CHECK-BASIC-LIBCXX-C-LINK-NOT: "-internal-isystem" "[[SYSROOT]]/usr/bin/../include/c++/v1"
// CHECK-BASIC-LIBCXX-C-LINK: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
// CHECK-BASIC-LIBCXX-C-LINK: "--sysroot=[[SYSROOT]]"
// CHECK-BASIC-LIBCXX-C-LINK: "-L[[SYSROOT]]/usr/bin/../lib"
//
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 -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i386-unknown-linux \
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: --sysroot=%S/Inputs/ubuntu_11.04_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-11-04 %s
// CHECK-UBUNTU-11-04: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-UBUNTU-11-04: "{{.*}}/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
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: "-L[[SYSROOT]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5"
// CHECK-UBUNTU-11-04: "-L[[SYSROOT]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../i386-linux-gnu"
// CHECK-UBUNTU-11-04: "-L[[SYSROOT]]/usr/lib/i386-linux-gnu"
// CHECK-UBUNTU-11-04: "-L[[SYSROOT]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../.."
// CHECK-UBUNTU-11-04: "-L[[SYSROOT]]/lib"
// CHECK-UBUNTU-11-04: "-L[[SYSROOT]]/usr/lib"
add tree test for suse on ppc64 (r146142) llvm-svn: 146176
2011-12-09 04:36:19 +08:00
//
Support ARM hard float (arm-linux-gnueabihf). llvm-svn: 161038
2012-07-31 16:06:29 +08:00
// Check multi arch support on Ubuntu 12.04 LTS.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=arm-unknown-linux-gnueabihf \
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="" \
Support ARM hard float (arm-linux-gnueabihf). llvm-svn: 161038
2012-07-31 16:06:29 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_12.04_LTS_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-12-04-ARM-HF %s
// CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf{{/|\\\\}}crt1.o"
// CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf{{/|\\\\}}crti.o"
// CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3{{/|\\\\}}crtbegin.o"
Support ARM hard float (arm-linux-gnueabihf). llvm-svn: 161038
2012-07-31 16:06:29 +08:00
// CHECK-UBUNTU-12-04-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabihf/4.6.3"
// CHECK-UBUNTU-12-04-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf"
// CHECK-UBUNTU-12-04-ARM-HF: "-L[[SYSROOT]]/lib/arm-linux-gnueabihf"
// CHECK-UBUNTU-12-04-ARM-HF: "-L[[SYSROOT]]/usr/lib/arm-linux-gnueabihf"
// CHECK-UBUNTU-12-04-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../.."
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3{{/|\\\\}}crtend.o"
// CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf{{/|\\\\}}crtn.o"
Support cross linking to arm on ubuntu. With this patch we correctly determine that ubuntu's ARM tree is not biarch and use "lib" istead of "lib32". Without this patch the search inside the arm tree for the crt files was failing and we would end up trying to use the i686 ones in lib32. llvm-svn: 193528
2013-10-29 02:52:30 +08:00
//
Teach the driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// Check Ubuntu 13.10 on x86-64 targeting arm-linux-gnueabihf.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-gnueabihf \
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 driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// RUN: --sysroot=%S/Inputs/x86-64_ubuntu_13.10 \
// RUN: | FileCheck --check-prefix=CHECK-X86-64-UBUNTU-13-10-ARM-HF %s
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "-dynamic-linker" "{{(/usr/arm--linux-gnueabihf)?}}/lib/ld-linux-armhf.so.3"
Teach the driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib{{/|\\\\}}crt1.o"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib{{/|\\\\}}crti.o"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8{{/|\\\\}}crtbegin.o"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "-L[[SYSROOT]]/lib/../lib"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "-L[[SYSROOT]]/usr/lib/../lib"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8{{/|\\\\}}crtend.o"
// CHECK-X86-64-UBUNTU-13-10-ARM-HF: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/lib/../lib{{/|\\\\}}crtn.o"
//
// Check Ubuntu 13.10 on x86-64 targeting arm-linux-gnueabi.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-gnueabi \
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 driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// RUN: --sysroot=%S/Inputs/x86-64_ubuntu_13.10 \
// RUN: | FileCheck --check-prefix=CHECK-X86-64-UBUNTU-13-10-ARM %s
// CHECK-X86-64-UBUNTU-13-10-ARM: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-X86-64-UBUNTU-13-10-ARM: "-dynamic-linker" "{{(/usr/arm--linux-gnueabi)?}}/lib/ld-linux.so.3"
Teach the driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// CHECK-X86-64-UBUNTU-13-10-ARM: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/lib/../lib{{/|\\\\}}crt1.o"
// CHECK-X86-64-UBUNTU-13-10-ARM: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/lib/../lib{{/|\\\\}}crti.o"
// CHECK-X86-64-UBUNTU-13-10-ARM: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabi/4.7{{/|\\\\}}crtbegin.o"
// CHECK-X86-64-UBUNTU-13-10-ARM: "-L[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabi/4.7"
// CHECK-X86-64-UBUNTU-13-10-ARM: "-L[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/lib/../lib"
// CHECK-X86-64-UBUNTU-13-10-ARM: "-L[[SYSROOT]]/lib/../lib"
// CHECK-X86-64-UBUNTU-13-10-ARM: "-L[[SYSROOT]]/usr/lib/../lib"
// CHECK-X86-64-UBUNTU-13-10-ARM: "-L[[SYSROOT]]/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/lib"
// CHECK-X86-64-UBUNTU-13-10-ARM: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabi/4.7{{/|\\\\}}crtend.o"
// CHECK-X86-64-UBUNTU-13-10-ARM: "{{.*}}/usr/lib/gcc-cross/arm-linux-gnueabi/4.7/../../../../arm-linux-gnueabi/lib/../lib{{/|\\\\}}crtn.o"
//
[PowerPC] Fix ELF interpreter name for powerpc64le-linux On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version). This fixes the clang driver to pass the appropriate -dynamic-linker setting, and adds some more tests to linux-ld.c. llvm-svn: 211360
2014-06-20 22:19:02 +08:00
// Check Ubuntu 14.04 on powerpc64le.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc64le-unknown-linux-gnu \
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] Fix ELF interpreter name for powerpc64le-linux On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version). This fixes the clang driver to pass the appropriate -dynamic-linker setting, and adds some more tests to linux-ld.c. llvm-svn: 211360
2014-06-20 22:19:02 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-14-04-PPC64LE %s
// CHECK-UBUNTU-14-04-PPC64LE: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-14-04-PPC64LE: "{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu{{/|\\\\}}crt1.o"
// CHECK-UBUNTU-14-04-PPC64LE: "{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu{{/|\\\\}}crti.o"
// CHECK-UBUNTU-14-04-PPC64LE: "{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8{{/|\\\\}}crtbegin.o"
// CHECK-UBUNTU-14-04-PPC64LE: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8"
// CHECK-UBUNTU-14-04-PPC64LE: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu"
// CHECK-UBUNTU-14-04-PPC64LE: "-L[[SYSROOT]]/lib/powerpc64le-linux-gnu"
// CHECK-UBUNTU-14-04-PPC64LE: "-L[[SYSROOT]]/usr/lib/powerpc64le-linux-gnu"
// CHECK-UBUNTU-14-04-PPC64LE: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../.."
// CHECK-UBUNTU-14-04-PPC64LE: "{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8{{/|\\\\}}crtend.o"
// CHECK-UBUNTU-14-04-PPC64LE: "{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu{{/|\\\\}}crtn.o"
//
[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 on x32.
// "/usr/lib/gcc/x86_64-linux-gnu/4.8/x32/crtend.o" "/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32/crtn.o"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnux32 \
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: --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-14-04-X32 %s
// CHECK-UBUNTU-14-04-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-UBUNTU-14-04-X32: "{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32{{/|\\\\}}crt1.o"
// CHECK-UBUNTU-14-04-X32: "{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32{{/|\\\\}}crti.o"
// CHECK-UBUNTU-14-04-X32: "{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/x32{{/|\\\\}}crtbegin.o"
// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/x32"
// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32"
// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/lib/../libx32"
// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/../libx32"
// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/x86_64-linux-gnu/../../libx32"
// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8"
// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.."
// CHECK-UBUNTU-14-04-X32: "{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/x32{{/|\\\\}}crtend.o"
// CHECK-UBUNTU-14-04-X32: "{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32{{/|\\\\}}crtn.o"
//
Add driver support for fedora 18 on ARM. llvm-svn: 179484
2013-04-14 18:14:21 +08:00
// Check fedora 18 on arm.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=armv7-unknown-linux-gnueabihf \
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="" \
Add driver support for fedora 18 on ARM. llvm-svn: 179484
2013-04-14 18:14:21 +08:00
// RUN: --sysroot=%S/Inputs/fedora_18_tree \
// RUN: | FileCheck --check-prefix=CHECK-FEDORA-18-ARM-HF %s
// CHECK-FEDORA-18-ARM-HF: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Teach the driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// CHECK-FEDORA-18-ARM-HF: "{{.*}}/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2/../../../../lib{{/|\\\\}}crt1.o"
// CHECK-FEDORA-18-ARM-HF: "{{.*}}/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2/../../../../lib{{/|\\\\}}crti.o"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-FEDORA-18-ARM-HF: "{{.*}}/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2{{/|\\\\}}crtbegin.o"
Add driver support for fedora 18 on ARM. llvm-svn: 179484
2013-04-14 18:14:21 +08:00
// CHECK-FEDORA-18-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2"
Teach the driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// CHECK-FEDORA-18-ARM-HF: "-L[[SYSROOT]]/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2/../../../../lib"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-FEDORA-18-ARM-HF: "{{.*}}/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2{{/|\\\\}}crtend.o"
Teach the driver to not try to use 'lib32' multilib spellings on ARM which doesn't use that multilib. As a consequence, fix Clang's support for cross compiling environments that were relying on this quirk to ensure the correct library search path ordering. This also re-instates the new test cases from Rafael's r193528 for cross-compiling to ARM on Ubuntu 13.10 without any of the changes to the existing test cases (they were no longer needed). This solution was the result of a lot of IRC debugging and trying to understand *exactly* what quirk was being relied upon. It took some time for me to figure out that it was the use of 'lib32' is a multilib that was throwing a wrench in the works. In case you are thinking that its silly to use a multilib of 'lib' at all, entertainingly, GCC does so as well (you can see it with the .../lib/../lib/crt1.o pattern it uses), and the 2-phase sequence of search paths (multilib followed by non-multilib) has observable (if dubious) consequences. =/ Yuck. llvm-svn: 193601
2013-10-29 18:27:30 +08:00
// CHECK-FEDORA-18-ARM-HF: "{{.*}}/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.7.2/../../../../lib{{/|\\\\}}crtn.o"
Add driver support for fedora 18 on ARM. llvm-svn: 179484
2013-04-14 18:14:21 +08:00
//
Add driver support for AArch64 Fedora. Reviewed by Eric Christopher. llvm-svn: 208105
2014-05-07 00:58:14 +08:00
// Check Fedora 21 on AArch64.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm64-unknown-linux-gnu \
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="" \
Add driver support for AArch64 Fedora. Reviewed by Eric Christopher. llvm-svn: 208105
2014-05-07 00:58:14 +08:00
// RUN: --sysroot=%S/Inputs/fedora_21_tree \
// RUN: | FileCheck --check-prefix=CHECK-FEDORA-21-AARCH64 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=aarch64-unknown-linux-gnu \
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="" \
Add driver support for AArch64 Fedora. Reviewed by Eric Christopher. llvm-svn: 208105
2014-05-07 00:58:14 +08:00
// RUN: --sysroot=%S/Inputs/fedora_21_tree \
// RUN: | FileCheck --check-prefix=CHECK-FEDORA-21-AARCH64 %s
// CHECK-FEDORA-21-AARCH64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-FEDORA-21-AARCH64: "{{.*}}/usr/lib/gcc/aarch64-redhat-linux/4.9.0/../../../../lib64{{/|\\\\}}crt1.o"
// CHECK-FEDORA-21-AARCH64: "{{.*}}/usr/lib/gcc/aarch64-redhat-linux/4.9.0/../../../../lib64{{/|\\\\}}crti.o"
// CHECK-FEDORA-21-AARCH64: "{{.*}}/usr/lib/gcc/aarch64-redhat-linux/4.9.0{{/|\\\\}}crtbegin.o"
// CHECK-FEDORA-21-AARCH64: "-L[[SYSROOT]]/usr/lib/gcc/aarch64-redhat-linux/4.9.0"
// CHECK-FEDORA-21-AARCH64: "-L[[SYSROOT]]/usr/lib/gcc/aarch64-redhat-linux/4.9.0/../../../../lib64"
// CHECK-FEDORA-21-AARCH64: "{{.*}}/usr/lib/gcc/aarch64-redhat-linux/4.9.0{{/|\\\\}}crtend.o"
// CHECK-FEDORA-21-AARCH64: "{{.*}}/usr/lib/gcc/aarch64-redhat-linux/4.9.0/../../../../lib64{{/|\\\\}}crtn.o"
//
Support ARM hard float (arm-linux-gnueabihf). llvm-svn: 161038
2012-07-31 16:06:29 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=arm-unknown-linux-gnueabi \
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="" \
Support ARM hard float (arm-linux-gnueabihf). llvm-svn: 161038
2012-07-31 16:06:29 +08:00
// RUN: --sysroot=%S/Inputs/ubuntu_12.04_LTS_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-UBUNTU-12-04-ARM %s
// CHECK-UBUNTU-12-04-ARM: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-UBUNTU-12-04-ARM: "{{.*}}/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../arm-linux-gnueabi{{/|\\\\}}crt1.o"
// CHECK-UBUNTU-12-04-ARM: "{{.*}}/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../arm-linux-gnueabi{{/|\\\\}}crti.o"
// CHECK-UBUNTU-12-04-ARM: "{{.*}}/usr/lib/gcc/arm-linux-gnueabi/4.6.1{{/|\\\\}}crtbegin.o"
Support ARM hard float (arm-linux-gnueabihf). llvm-svn: 161038
2012-07-31 16:06:29 +08:00
// CHECK-UBUNTU-12-04-ARM: "-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabi/4.6.1"
// CHECK-UBUNTU-12-04-ARM: "-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../arm-linux-gnueabi"
// CHECK-UBUNTU-12-04-ARM: "-L[[SYSROOT]]/lib/arm-linux-gnueabi"
// CHECK-UBUNTU-12-04-ARM: "-L[[SYSROOT]]/usr/lib/arm-linux-gnueabi"
// CHECK-UBUNTU-12-04-ARM: "-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../.."
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-UBUNTU-12-04-ARM: "{{.*}}/usr/lib/gcc/arm-linux-gnueabi/4.6.1{{/|\\\\}}crtend.o"
// CHECK-UBUNTU-12-04-ARM: "{{.*}}/usr/lib/gcc/arm-linux-gnueabi/4.6.1/../../../arm-linux-gnueabi{{/|\\\\}}crtn.o"
Support ARM hard float (arm-linux-gnueabihf). llvm-svn: 161038
2012-07-31 16:06:29 +08:00
//
add tree test for suse on ppc64 (r146142) llvm-svn: 146176
2011-12-09 04:36:19 +08:00
// Test the setup that shipped in SUSE 10.3 on ppc64.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=powerpc64-suse-linux \
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="" \
add tree test for suse on ppc64 (r146142) llvm-svn: 146176
2011-12-09 04:36:19 +08:00
// RUN: --sysroot=%S/Inputs/suse_10.3_ppc64_tree \
// RUN: | FileCheck --check-prefix=CHECK-SUSE-10-3-PPC64 %s
// CHECK-SUSE-10-3-PPC64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-SUSE-10-3-PPC64: "{{.*}}/usr/lib/gcc/powerpc64-suse-linux/4.1.2/64{{/|\\\\}}crtbegin.o"
add tree test for suse on ppc64 (r146142) llvm-svn: 146176
2011-12-09 04:36:19 +08:00
// CHECK-SUSE-10-3-PPC64: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64-suse-linux/4.1.2/64"
// CHECK-SUSE-10-3-PPC64: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64-suse-linux/4.1.2/../../../../lib64"
// CHECK-SUSE-10-3-PPC64: "-L[[SYSROOT]]/lib/../lib64"
// CHECK-SUSE-10-3-PPC64: "-L[[SYSROOT]]/usr/lib/../lib64"
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
//
[Driver] Add openSuse AArch64 Triple Summary: openSuse has AArch64 support, with images running on the Raspberry Pi 3. The libraries and headers live under the aarch64-suse-linux subdirectory, which is currently not in the AArch64 triples list. Address this by adding the corresponding string to AArch64Triples. Reviewers: chandlerc, bruno, bkramer, rengolin Subscribers: aemerson, rengolin, cfe-commits Differential Revision: https://reviews.llvm.org/D28238 llvm-svn: 291598
2017-01-11 05:13:08 +08:00
// Check openSuse Leap 42.2 on AArch64
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm64-unknown-linux-gnu \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/opensuse_42.2_aarch64_tree \
// RUN: | FileCheck --check-prefix=CHECK-OPENSUSE-42-2-AARCH64 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=aarch64-unknown-linux-gnu \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/opensuse_42.2_aarch64_tree \
// RUN: | FileCheck --check-prefix=CHECK-OPENSUSE-42-2-AARCH64 %s
// CHECK-OPENSUSE-42-2-AARCH64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-OPENSUSE-42-2-AARCH64: "{{.*}}/usr/lib64/gcc/aarch64-suse-linux/4.8/../../../../lib64{{/|\\\\}}crt1.o"
// CHECK-OPENSUSE-42-2-AARCH64: "{{.*}}/usr/lib64/gcc/aarch64-suse-linux/4.8/../../../../lib64{{/|\\\\}}crti.o"
// CHECK-OPENSUSE-42-2-AARCH64: "{{.*}}/usr/lib64/gcc/aarch64-suse-linux/4.8{{/|\\\\}}crtbegin.o"
// CHECK-OPENSUSE-42-2-AARCH64: "-L[[SYSROOT]]/usr/lib64/gcc/aarch64-suse-linux/4.8"
// CHECK-OPENSUSE-42-2-AARCH64: "-L[[SYSROOT]]/usr/lib64/gcc/aarch64-suse-linux/4.8/../../../../lib64"
// CHECK-OPENSUSE-42-2-AARCH64: "{{.*}}/usr/lib64/gcc/aarch64-suse-linux/4.8{{/|\\\\}}crtend.o"
// CHECK-OPENSUSE-42-2-AARCH64: "{{.*}}/usr/lib64/gcc/aarch64-suse-linux/4.8/../../../../lib64{{/|\\\\}}crtn.o"
//
Add support for openSUSE ARM Triples Summary: Add support for armv6hl-suse-linux-gnueabi and armv7hl-suse-linux-gnueabi triples used by openSUSE/SUSE. Reviewers: cfe-commits, rovka, compnerd, rengolin Reviewed By: rengolin Subscribers: aemerson, rengolin, bkramer, chandlerc Differential Revision: https://reviews.llvm.org/D32347 llvm-svn: 300969
2017-04-21 20:26:43 +08:00
// Check openSUSE Tumbleweed on armv6hl
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=armv6hl-suse-linux-gnueabi \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/opensuse_tumbleweed_armv6hl_tree \
// RUN: | FileCheck --check-prefix=CHECK-OPENSUSE-TW-ARMV6HL %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=armv6hl-suse-linux-gnueabi \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/opensuse_tumbleweed_armv6hl_tree \
// RUN: | FileCheck --check-prefix=CHECK-OPENSUSE-TW-ARMV6HL %s
// CHECK-OPENSUSE-TW-ARMV6HL: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-OPENSUSE-TW-ARMV6HL: "{{.*}}/usr/lib/gcc/armv6hl-suse-linux-gnueabi/5/../../../../lib{{/|\\\\}}crt1.o"
// CHECK-OPENSUSE-TW-ARMV6HL: "{{.*}}/usr/lib/gcc/armv6hl-suse-linux-gnueabi/5/../../../../lib{{/|\\\\}}crti.o"
// CHECK-OPENSUSE-TW-ARMV6HL: "{{.*}}/usr/lib/gcc/armv6hl-suse-linux-gnueabi/5{{/|\\\\}}crtbegin.o"
// CHECK-OPENSUSE-TW-ARMV6HL: "-L[[SYSROOT]]/usr/lib/gcc/armv6hl-suse-linux-gnueabi/5"
// CHECK-OPENSUSE-TW-ARMV6HL: "-L[[SYSROOT]]/usr/lib/gcc/armv6hl-suse-linux-gnueabi/5/../../../../lib"
// CHECK-OPENSUSE-TW-ARMV6HL: "{{.*}}/usr/lib/gcc/armv6hl-suse-linux-gnueabi/5{{/|\\\\}}crtend.o"
// CHECK-OPENSUSE-TW-ARMV6HL: "{{.*}}/usr/lib/gcc/armv6hl-suse-linux-gnueabi/5/../../../../lib{{/|\\\\}}crtn.o"
//
// Check openSUSE Tumbleweed on armv7hl
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=armv7hl-suse-linux-gnueabi \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/opensuse_tumbleweed_armv7hl_tree \
// RUN: | FileCheck --check-prefix=CHECK-OPENSUSE-TW-ARMV7HL %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=armv7hl-suse-linux-gnueabi \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/opensuse_tumbleweed_armv7hl_tree \
// RUN: | FileCheck --check-prefix=CHECK-OPENSUSE-TW-ARMV7HL %s
// CHECK-OPENSUSE-TW-ARMV7HL: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-OPENSUSE-TW-ARMV7HL: "{{.*}}/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5/../../../../lib{{/|\\\\}}crt1.o"
// CHECK-OPENSUSE-TW-ARMV7HL: "{{.*}}/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5/../../../../lib{{/|\\\\}}crti.o"
// CHECK-OPENSUSE-TW-ARMV7HL: "{{.*}}/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5{{/|\\\\}}crtbegin.o"
// CHECK-OPENSUSE-TW-ARMV7HL: "-L[[SYSROOT]]/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5"
// CHECK-OPENSUSE-TW-ARMV7HL: "-L[[SYSROOT]]/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5/../../../../lib"
// CHECK-OPENSUSE-TW-ARMV7HL: "{{.*}}/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5{{/|\\\\}}crtend.o"
// CHECK-OPENSUSE-TW-ARMV7HL: "{{.*}}/usr/lib/gcc/armv7hl-suse-linux-gnueabi/5/../../../../lib{{/|\\\\}}crtn.o"
//
Fix dynamic object linker for ARM GNUEABIHF. llvm-svn: 160958
2012-07-30 19:05:56 +08:00
// Check dynamic-linker for different archs
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=arm-linux-gnueabi \
Fix dynamic object linker for ARM GNUEABIHF. llvm-svn: 160958
2012-07-30 19:05:56 +08:00
// RUN: | FileCheck --check-prefix=CHECK-ARM %s
// CHECK-ARM: "{{.*}}ld{{(.exe)?}}"
// CHECK-ARM: "-m" "armelf_linux_eabi"
// CHECK-ARM: "-dynamic-linker" "{{.*}}/lib/ld-linux.so.3"
//
// RUN: %clang %s -### -o %t.o 2>&1 \
Setting ARM dynamic linker name from commandline Currently trigger to select hard-float linker is only based of -gnueabihf appearing in target triplet, but we should also select it when hardfloat is requested via cmdline. Patch by Khem Raj. llvm-svn: 243262
2015-07-27 17:56:37 +08:00
// RUN: --target=arm-linux-gnueabi -mfloat-abi=hard \
// RUN: | FileCheck --check-prefix=CHECK-ARM-ABIHF %s
// CHECK-ARM-ABIHF: "{{.*}}ld{{(.exe)?}}"
// CHECK-ARM-ABIHF: "-m" "armelf_linux_eabi"
// CHECK-ARM-ABIHF: "-dynamic-linker" "{{.*}}/lib/ld-linux-armhf.so.3"
//
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=arm-linux-gnueabihf \
Fix dynamic object linker for ARM GNUEABIHF. llvm-svn: 160958
2012-07-30 19:05:56 +08:00
// RUN: | FileCheck --check-prefix=CHECK-ARM-HF %s
// CHECK-ARM-HF: "{{.*}}ld{{(.exe)?}}"
// CHECK-ARM-HF: "-m" "armelf_linux_eabi"
// CHECK-ARM-HF: "-dynamic-linker" "{{.*}}/lib/ld-linux-armhf.so.3"
//
[PowerPC] Fix ELF interpreter name for powerpc64le-linux On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version). This fixes the clang driver to pass the appropriate -dynamic-linker setting, and adds some more tests to linux-ld.c. llvm-svn: 211360
2014-06-20 22:19:02 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
// RUN: --target=powerpc64-linux-gnu \
// RUN: | FileCheck --check-prefix=CHECK-PPC64 %s
// CHECK-PPC64: "{{.*}}ld{{(.exe)?}}"
// CHECK-PPC64: "-m" "elf64ppc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-PPC64: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld64.so.1"
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc64-linux-gnu -mabi=elfv1 \
// RUN: | FileCheck --check-prefix=CHECK-PPC64-ELFv1 %s
[PowerPC] ABI support for the QPX vector instruction set Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer, has recently been added to the LLVM PowerPC backend. This vector instruction set requires some ABI modifications because the ABI on the BG/Q expects <4 x double> vectors to be provided with 32-byte stack alignment, and to be handled as native vector types (similar to how Altivec vectors are handled on mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this the default ABI when QPX is supported, and have updated the ABI handling code to provide QPX vectors with the correct stack alignment and associated register-assignment logic. llvm-svn: 231960
2015-03-12 03:14:15 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc64-linux-gnu -mabi=elfv1-qpx \
// RUN: | FileCheck --check-prefix=CHECK-PPC64-ELFv1 %s
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
// CHECK-PPC64-ELFv1: "{{.*}}ld{{(.exe)?}}"
// CHECK-PPC64-ELFv1: "-m" "elf64ppc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-PPC64-ELFv1: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld64.so.1"
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc64-linux-gnu -mabi=elfv2 \
// RUN: | FileCheck --check-prefix=CHECK-PPC64-ELFv2 %s
// CHECK-PPC64-ELFv2: "{{.*}}ld{{(.exe)?}}"
// CHECK-PPC64-ELFv2: "-m" "elf64ppc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-PPC64-ELFv2: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld64.so.2"
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 \
[PowerPC] Fix ELF interpreter name for powerpc64le-linux On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version). This fixes the clang driver to pass the appropriate -dynamic-linker setting, and adds some more tests to linux-ld.c. llvm-svn: 211360
2014-06-20 22:19:02 +08:00
// RUN: --target=powerpc64le-linux-gnu \
// RUN: | FileCheck --check-prefix=CHECK-PPC64LE %s
// CHECK-PPC64LE: "{{.*}}ld{{(.exe)?}}"
// CHECK-PPC64LE: "-m" "elf64lppc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-PPC64LE: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld64.so.2"
[PowerPC] Fix ELF interpreter name for powerpc64le-linux On PowerPC LE the system uses the /lib64/ld64.so.2 dynamic linker name instead of /lib64/ld64.so.1 (to indicate the ELFv2 ABI version). This fixes the clang driver to pass the appropriate -dynamic-linker setting, and adds some more tests to linux-ld.c. llvm-svn: 211360
2014-06-20 22:19:02 +08:00
//
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc64le-linux-gnu -mabi=elfv1 \
// RUN: | FileCheck --check-prefix=CHECK-PPC64LE-ELFv1 %s
// CHECK-PPC64LE-ELFv1: "{{.*}}ld{{(.exe)?}}"
// CHECK-PPC64LE-ELFv1: "-m" "elf64lppc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-PPC64LE-ELFv1: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld64.so.1"
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc64le-linux-gnu -mabi=elfv2 \
// RUN: | FileCheck --check-prefix=CHECK-PPC64LE-ELFv2 %s
// CHECK-PPC64LE-ELFv2: "{{.*}}ld{{(.exe)?}}"
// CHECK-PPC64LE-ELFv2: "-m" "elf64lppc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-PPC64LE-ELFv2: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld64.so.2"
[PowerPC] Support ELFv1/ELFv2 ABI selection via -mabi= option While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently hard-coded via the target triple: powerpc64-linux is always ELFv1, while powerpc64le-linux is always ELFv2. These are of course the most common scenarios, but in principle it is possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on little-endian systems (and GCC does support that), and there are some special use cases for that (e.g. certain Linux kernel versions could only be built using ELFv1 on LE). This patch implements the Clang side of supporting this, based on the LLVM commit 214072. The command line options -mabi=elfv1 or -mabi=elfv2 select the desired ABI if present. (If not, Clang uses the same default rules as now.) Specifically, the patch implements the following changes based on the presence of the -mabi= option: In the driver: - Pass the appropiate -target-abi flag to the back-end - Select the correct dynamic loader version (/lib64/ld64.so.[12]) In the preprocessor: - Define _CALL_ELF to the appropriate value (1 or 2) In the compiler back-end: - Select the correct ABI in TargetInfo.cpp - Select the desired ABI for LLVM via feature (elfv1/elfv2) llvm-svn: 214074
2014-07-28 21:17:52 +08:00
//
[Hexagon] Linux linker does not support .gnu-hash Hexagon Linux dynamic loader does not use (in fact does not support) .gnu-hash Differential Revision: https://reviews.llvm.org/D28865 llvm-svn: 292496
2017-01-20 00:54:04 +08:00
// Check that we do not pass --hash-style=gnu or --hash-style=both to
// hexagon linux linker
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=hexagon-linux-gnu \
// RUN: | FileCheck --check-prefix=CHECK-HEXAGON %s
// CHECK-HEXAGON: "{{.*}}hexagon-link{{(.exe)?}}"
// CHECK-HEXAGON-NOT: "--hash-style={{gnu|both}}"
//
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// Check that we do not pass --hash-style=gnu and --hash-style=both to linker
MIPS: Provide a correct path to the dynamic linker when build for MIPS 64-bit targets. llvm-svn: 154200
2012-04-07 04:14:27 +08:00
// and provide correct path to the dynamic linker and emulation mode when build
// for MIPS platforms.
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips-linux-gnu \
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPS %s
// CHECK-MIPS: "{{.*}}ld{{(.exe)?}}"
MIPS: Provide a correct path to the dynamic linker when build for MIPS 64-bit targets. llvm-svn: 154200
2012-04-07 04:14:27 +08:00
// CHECK-MIPS: "-m" "elf32btsmip"
// CHECK-MIPS: "-dynamic-linker" "{{.*}}/lib/ld.so.1"
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// CHECK-MIPS-NOT: "--hash-style={{gnu|both}}"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
//
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mipsel-linux-gnu \
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPSEL %s
// CHECK-MIPSEL: "{{.*}}ld{{(.exe)?}}"
MIPS: Provide a correct path to the dynamic linker when build for MIPS 64-bit targets. llvm-svn: 154200
2012-04-07 04:14:27 +08:00
// CHECK-MIPSEL: "-m" "elf32ltsmip"
// CHECK-MIPSEL: "-dynamic-linker" "{{.*}}/lib/ld.so.1"
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// CHECK-MIPSEL-NOT: "--hash-style={{gnu|both}}"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 --target=mipsel-linux-gnu -mnan=2008 \
// RUN: | FileCheck --check-prefix=CHECK-MIPSEL-NAN2008 %s
// CHECK-MIPSEL-NAN2008: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPSEL-NAN2008: "-m" "elf32ltsmip"
// CHECK-MIPSEL-NAN2008: "-dynamic-linker" "{{.*}}/lib/ld-linux-mipsn8.so.1"
// CHECK-MIPSEL-NAN2008-NOT: "--hash-style={{gnu|both}}"
//
// RUN: %clang %s -### -o %t.o 2>&1 --target=mipsel-linux-gnu -mcpu=mips32r6 \
// RUN: | FileCheck --check-prefix=CHECK-MIPS32R6EL %s
// CHECK-MIPS32R6EL: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPS32R6EL: "-m" "elf32ltsmip"
// CHECK-MIPS32R6EL: "-dynamic-linker" "{{.*}}/lib/ld-linux-mipsn8.so.1"
// CHECK-MIPS32R6EL-NOT: "--hash-style={{gnu|both}}"
//
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64-linux-gnu \
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPS64 %s
// CHECK-MIPS64: "{{.*}}ld{{(.exe)?}}"
MIPS: Provide a correct path to the dynamic linker when build for MIPS 64-bit targets. llvm-svn: 154200
2012-04-07 04:14:27 +08:00
// CHECK-MIPS64: "-m" "elf64btsmip"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld.so.1"
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// CHECK-MIPS64-NOT: "--hash-style={{gnu|both}}"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
//
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64el-linux-gnu \
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPS64EL %s
// CHECK-MIPS64EL: "{{.*}}ld{{(.exe)?}}"
MIPS: Provide a correct path to the dynamic linker when build for MIPS 64-bit targets. llvm-svn: 154200
2012-04-07 04:14:27 +08:00
// CHECK-MIPS64EL: "-m" "elf64ltsmip"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64EL: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld.so.1"
Teach the link-step test to verify that we don't pass bad --hash-style flags on MIPS paltforms. llvm-svn: 146837
2011-12-18 05:57:25 +08:00
// CHECK-MIPS64EL-NOT: "--hash-style={{gnu|both}}"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 --target=mips64el-linux-gnu -mnan=2008 \
// RUN: | FileCheck --check-prefix=CHECK-MIPS64EL-NAN2008 %s
// CHECK-MIPS64EL-NAN2008: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPS64EL-NAN2008: "-m" "elf64ltsmip"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64EL-NAN2008: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld-linux-mipsn8.so.1"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
// CHECK-MIPS64EL-NAN2008-NOT: "--hash-style={{gnu|both}}"
//
// RUN: %clang %s -### -o %t.o 2>&1 --target=mips64el-linux-gnu -mcpu=mips64r6 \
// RUN: | FileCheck --check-prefix=CHECK-MIPS64R6EL %s
// CHECK-MIPS64R6EL: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPS64R6EL: "-m" "elf64ltsmip"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64R6EL: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld-linux-mipsn8.so.1"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
// CHECK-MIPS64R6EL-NOT: "--hash-style={{gnu|both}}"
//
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64-linux-gnu -mabi=n32 \
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPS64-N32 %s
// CHECK-MIPS64-N32: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPS64-N32: "-m" "elf32btsmipn32"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64-N32: "-dynamic-linker" "{{.*}}/lib{{(32)?}}/ld.so.1"
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// CHECK-MIPS64-N32-NOT: "--hash-style={{gnu|both}}"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
//
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64el-linux-gnu -mabi=n32 \
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MIPS64EL-N32 %s
// CHECK-MIPS64EL-N32: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPS64EL-N32: "-m" "elf32ltsmipn32"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64EL-N32: "-dynamic-linker" "{{.*}}/lib{{(32)?}}/ld.so.1"
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// CHECK-MIPS64EL-N32-NOT: "--hash-style={{gnu|both}}"
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
//
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 --target=mips64el-linux-gnu -mabi=n32 \
// RUN: -mnan=2008 | FileCheck --check-prefix=CHECK-MIPS64EL-N32-NAN2008 %s
// CHECK-MIPS64EL-N32-NAN2008: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPS64EL-N32-NAN2008: "-m" "elf32ltsmipn32"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64EL-N32-NAN2008: "-dynamic-linker" "{{.*}}/lib{{(32)?}}/ld-linux-mipsn8.so.1"
[mips] Correct linux dynamic linker for -mnan=2008 Summary: The dynamic linker is named ld-linux-mipsn8.so.1 when -mnan=2008 is given (or is the default). It remains ld.so.1 for other cases. This is necessary for MIPS32r6/MIPS64r6 since these ISA's default to -mnan=2008. Differential Revision: http://reviews.llvm.org/D4273 llvm-svn: 211598
2014-06-24 23:04:16 +08:00
// CHECK-MIPS64EL-N32-NAN2008-NOT: "--hash-style={{gnu|both}}"
//
[mips] Add test for the dynamic linker when using the mips64el-fedora-linux triple. We should use the musl linker only when there's no environment specified and the vendor is MTI. The new test verifies this behaviour and is a follow-up to the r269411 commit that added the vendor field check. llvm-svn: 269651
2016-05-16 19:53:51 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 --target=mips64el-redhat-linux \
// RUN: | FileCheck --check-prefix=CHECK-MIPS64EL-REDHAT %s
// CHECK-MIPS64EL-REDHAT: "{{.*}}ld{{(.exe)?}}"
// CHECK-MIPS64EL-REDHAT: "-m" "elf64ltsmip"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-MIPS64EL-REDHAT: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld.so.1"
// CHECK-MIPS64EL-REDHAT-NOT: "-dynamic-linker" "{{.*}}/lib{{(64)?}}/ld-musl-mipsel.so.1"
[mips] Add test for the dynamic linker when using the mips64el-fedora-linux triple. We should use the musl linker only when there's no environment specified and the vendor is MTI. The new test verifies this behaviour and is a follow-up to the r269411 commit that added the vendor field check. llvm-svn: 269651
2016-05-16 19:53:51 +08:00
// CHECK-MIPS64EL-REDHAT-NOT: "--hash-style={{gnu|both}}"
//
Give the linker the right ELF type for SPARC targets. llvm-svn: 198912
2014-01-10 11:51:33 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
[Sparc] Add support for 'sparcel' to clang. Differential Revision: http://reviews.llvm.org/D8784 llvm-svn: 237001
2015-05-11 23:21:44 +08:00
// RUN: --target=sparc-unknown-linux-gnu \
Give the linker the right ELF type for SPARC targets. llvm-svn: 198912
2014-01-10 11:51:33 +08:00
// RUN: | FileCheck --check-prefix=CHECK-SPARCV8 %s
// CHECK-SPARCV8: "{{.*}}ld{{(.exe)?}}"
// CHECK-SPARCV8: "-m" "elf32_sparc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-SPARCV8: "-dynamic-linker" "{{(/usr/sparc-unknown-linux-gnu)?}}/lib/ld-linux.so.2"
Give the linker the right ELF type for SPARC targets. llvm-svn: 198912
2014-01-10 11:51:33 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 \
[Sparc] Add support for 'sparcel' to clang. Differential Revision: http://reviews.llvm.org/D8784 llvm-svn: 237001
2015-05-11 23:21:44 +08:00
// RUN: --target=sparcel-unknown-linux-gnu \
// RUN: | FileCheck --check-prefix=CHECK-SPARCV8EL %s
// CHECK-SPARCV8EL: "{{.*}}ld{{(.exe)?}}"
// CHECK-SPARCV8EL: "-m" "elf32_sparc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-SPARCV8EL: "-dynamic-linker" "{{(/usr/sparcel-unknown-linux-gnu)?}}/lib/ld-linux.so.2"
[Sparc] Add support for 'sparcel' to clang. Differential Revision: http://reviews.llvm.org/D8784 llvm-svn: 237001
2015-05-11 23:21:44 +08:00
//
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=sparcv9-unknown-linux-gnu \
Give the linker the right ELF type for SPARC targets. llvm-svn: 198912
2014-01-10 11:51:33 +08:00
// RUN: | FileCheck --check-prefix=CHECK-SPARCV9 %s
// CHECK-SPARCV9: "{{.*}}ld{{(.exe)?}}"
// CHECK-SPARCV9: "-m" "elf64_sparc"
Driver: support exherbo's multiarch support Exherbo has an alternative file system layout to accommodate multiarch. The loader is located at /usr/${triple}/lib/${loader}. Adjust the Linux toolchain to support that on exherbo. llvm-svn: 270392
2016-05-23 10:17:28 +08:00
// CHECK-SPARCV9: "-dynamic-linker" "{{(/usr/sparcv9-unknown-linux-gnu)?}}/lib{{(64)?}}/ld-linux.so.2"
Give the linker the right ELF type for SPARC targets. llvm-svn: 198912
2014-01-10 11:51:33 +08:00
//
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// Thoroughly exercise the Debian multiarch environment.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=i686-linux-gnu \
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="" \
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-X86 %s
// CHECK-DEBIAN-X86: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-X86: "{{.*}}/usr/lib/gcc/i686-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// CHECK-DEBIAN-X86: "-L[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.5"
// CHECK-DEBIAN-X86: "-L[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.5/../../../i386-linux-gnu"
// CHECK-DEBIAN-X86: "-L[[SYSROOT]]/usr/lib/i386-linux-gnu"
// CHECK-DEBIAN-X86: "-L[[SYSROOT]]/usr/lib/gcc/i686-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-X86: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-X86: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=x86_64-linux-gnu \
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="" \
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-X86-64 %s
// CHECK-DEBIAN-X86-64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-X86-64: "{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.5"
// CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.5/../../../x86_64-linux-gnu"
// CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/usr/lib/x86_64-linux-gnu"
// CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-X86-64: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=powerpc-linux-gnu \
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="" \
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-PPC %s
// CHECK-DEBIAN-PPC: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-PPC: "{{.*}}/usr/lib/gcc/powerpc-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// CHECK-DEBIAN-PPC: "-L[[SYSROOT]]/usr/lib/gcc/powerpc-linux-gnu/4.5"
// CHECK-DEBIAN-PPC: "-L[[SYSROOT]]/usr/lib/gcc/powerpc-linux-gnu/4.5/../../../powerpc-linux-gnu"
// CHECK-DEBIAN-PPC: "-L[[SYSROOT]]/usr/lib/powerpc-linux-gnu"
// CHECK-DEBIAN-PPC: "-L[[SYSROOT]]/usr/lib/gcc/powerpc-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-PPC: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-PPC: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
[PPC]: Fix bug in getMultiarchTriple. And generally prefer not to restate TargetTriple.str() over and over. Differential Revision: http://reviews.llvm.org/D10605 llvm-svn: 240808
2015-06-27 02:37:15 +08:00
// RUN: --target=powerpc64le-linux-gnu \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-PPC64LE %s
// CHECK-DEBIAN-PPC64LE: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-PPC64LE: "{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
// CHECK-DEBIAN-PPC64LE: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.5"
// CHECK-DEBIAN-PPC64LE: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.5/../../../powerpc64le-linux-gnu"
// CHECK-DEBIAN-PPC64LE: "-L[[SYSROOT]]/usr/lib/powerpc64le-linux-gnu"
// CHECK-DEBIAN-PPC64LE: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-PPC64LE: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-PPC64LE: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=powerpc64-linux-gnu \
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="" \
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-PPC64 %s
// CHECK-DEBIAN-PPC64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-PPC64: "{{.*}}/usr/lib/gcc/powerpc64-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
// CHECK-DEBIAN-PPC64: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64-linux-gnu/4.5"
// CHECK-DEBIAN-PPC64: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64-linux-gnu/4.5/../../../powerpc64-linux-gnu"
// CHECK-DEBIAN-PPC64: "-L[[SYSROOT]]/usr/lib/powerpc64-linux-gnu"
// CHECK-DEBIAN-PPC64: "-L[[SYSROOT]]/usr/lib/gcc/powerpc64-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-PPC64: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-PPC64: "-L[[SYSROOT]]/usr/lib"
MIPS: Add tests to check the debian multiarch stuff for mips and mipsel targets. llvm-svn: 155628
2012-04-26 16:35:58 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips-linux-gnu \
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="" \
MIPS: Add tests to check the debian multiarch stuff for mips and mipsel targets. llvm-svn: 155628
2012-04-26 16:35:58 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-MIPS %s
// CHECK-DEBIAN-MIPS: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-MIPS: "{{.*}}/usr/lib/gcc/mips-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
MIPS: Add tests to check the debian multiarch stuff for mips and mipsel targets. llvm-svn: 155628
2012-04-26 16:35:58 +08:00
// CHECK-DEBIAN-MIPS: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5"
// CHECK-DEBIAN-MIPS: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5/../../../mips-linux-gnu"
// CHECK-DEBIAN-MIPS: "-L[[SYSROOT]]/usr/lib/mips-linux-gnu"
// CHECK-DEBIAN-MIPS: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-MIPS: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-MIPS: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mipsel-linux-gnu \
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="" \
MIPS: Add tests to check the debian multiarch stuff for mips and mipsel targets. llvm-svn: 155628
2012-04-26 16:35:58 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-MIPSEL %s
// CHECK-DEBIAN-MIPSEL: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-MIPSEL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.5{{/|\\\\}}crtbegin.o"
MIPS: Add tests to check the debian multiarch stuff for mips and mipsel targets. llvm-svn: 155628
2012-04-26 16:35:58 +08:00
// CHECK-DEBIAN-MIPSEL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5"
// CHECK-DEBIAN-MIPSEL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5/../../../mipsel-linux-gnu"
// CHECK-DEBIAN-MIPSEL: "-L[[SYSROOT]]/usr/lib/mipsel-linux-gnu"
// CHECK-DEBIAN-MIPSEL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-MIPSEL: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-MIPSEL: "-L[[SYSROOT]]/usr/lib"
MIPS: Add support for 64-bit MIPS targets: mips64 / mips64el. llvm-svn: 155656
2012-04-27 03:57:02 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64-linux-gnu \
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="" \
MIPS: Add support for 64-bit MIPS targets: mips64 / mips64el. llvm-svn: 155656
2012-04-27 03:57:02 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-MIPS64 %s
// CHECK-DEBIAN-MIPS64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-MIPS64: "{{.*}}/usr/lib/gcc/mips-linux-gnu/4.5/64{{/|\\\\}}crtbegin.o"
MIPS: Add support for 64-bit MIPS targets: mips64 / mips64el. llvm-svn: 155656
2012-04-27 03:57:02 +08:00
// CHECK-DEBIAN-MIPS64: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5/64"
// CHECK-DEBIAN-MIPS64: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5"
// CHECK-DEBIAN-MIPS64: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-MIPS64: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-MIPS64: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64el-linux-gnu \
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="" \
MIPS: Add support for 64-bit MIPS targets: mips64 / mips64el. llvm-svn: 155656
2012-04-27 03:57:02 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-MIPS64EL %s
// CHECK-DEBIAN-MIPS64EL: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-MIPS64EL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.5/64{{/|\\\\}}crtbegin.o"
MIPS: Add support for 64-bit MIPS targets: mips64 / mips64el. llvm-svn: 155656
2012-04-27 03:57:02 +08:00
// CHECK-DEBIAN-MIPS64EL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5/64"
// CHECK-DEBIAN-MIPS64EL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5"
// CHECK-DEBIAN-MIPS64EL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-MIPS64EL: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-MIPS64EL: "-L[[SYSROOT]]/usr/lib"
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64-linux-gnu -mabi=n32 \
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="" \
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-MIPS64-N32 %s
// CHECK-DEBIAN-MIPS64-N32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-MIPS64-N32: "{{.*}}/usr/lib/gcc/mips-linux-gnu/4.5/n32{{/|\\\\}}crtbegin.o"
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// CHECK-DEBIAN-MIPS64-N32: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5/n32"
// CHECK-DEBIAN-MIPS64-N32: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5"
// CHECK-DEBIAN-MIPS64-N32: "-L[[SYSROOT]]/usr/lib/gcc/mips-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-MIPS64-N32: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-MIPS64-N32: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64el-linux-gnu -mabi=n32 \
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="" \
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: --sysroot=%S/Inputs/debian_multiarch_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-MIPS64EL-N32 %s
// CHECK-DEBIAN-MIPS64EL-N32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-MIPS64EL-N32: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.5/n32{{/|\\\\}}crtbegin.o"
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5/n32"
// CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5"
// CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.5/../../.."
// CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib"
Add support for PPC and PPC64 multiarch toolchains on Debain. Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added 64-bit support. I just added one other place where powerpc64-linux-gnu was missing (we only had powerpc64-unknown-linux-gnu). I've also added a tree to test out the debian multiarch stuff. I don't use debian regularly, so I'm not certain this is entirely accurate. If anyone wants to check it against a debian system and fix any inaccuracies, fire away. This way at least folks can see how this is *supposed* to be tested. It'd be particularly good to get the Debian MIPS toolchains tested in this way. llvm-svn: 151482
2012-02-26 17:03:21 +08:00
//
[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 linker paths on Debian 8 / Sparc
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=sparc-linux-gnu \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/debian_8_sparc_multilib_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-SPARC32 %s
// CHECK-DEBIAN-SPARC32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
[SPARC] Fix windows test failure after r239154. (Hopefully) llvm-svn: 239156
2015-06-05 22:16:39 +08:00
// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../sparc-linux-gnu{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../sparc-linux-gnu{{/|\\\\}}crti.o"
// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9{{/|\\\\}}crtbegin.o"
[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-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9"
// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../sparc-linux-gnu"
// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../lib"
// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/lib/sparc-linux-gnu"
// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib/sparc-linux-gnu"
// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-SPARC32: "-L[[SYSROOT]]/usr/lib"
[SPARC] Fix windows test failure after r239154. (Hopefully) llvm-svn: 239156
2015-06-05 22:16:39 +08:00
// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9{{/|\\\\}}crtend.o"
// CHECK-DEBIAN-SPARC32: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../sparc-linux-gnu{{/|\\\\}}crtn.o"
[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 linker paths on Debian 8 / Sparc, with the oldstyle multilib packages
// RUN: %clang -no-canonical-prefixes -m64 %s -### -o %t.o 2>&1 \
// RUN: --target=sparc-linux-gnu \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/debian_8_sparc_multilib_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-SPARC32-LIB64 %s
// CHECK-DEBIAN-SPARC32-LIB64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
[SPARC] Fix windows test failure after r239154. (Hopefully) llvm-svn: 239156
2015-06-05 22:16:39 +08:00
// CHECK-DEBIAN-SPARC32-LIB64: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../lib64{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-SPARC32-LIB64: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../lib64{{/|\\\\}}crti.o"
// CHECK-DEBIAN-SPARC32-LIB64: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/64{{/|\\\\}}crtbegin.o"
[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-DEBIAN-SPARC32-LIB64: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/64"
// CHECK-DEBIAN-SPARC32-LIB64: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../lib64"
// CHECK-DEBIAN-SPARC32-LIB64: "-L[[SYSROOT]]/lib/../lib64"
// CHECK-DEBIAN-SPARC32-LIB64: "-L[[SYSROOT]]/usr/lib/../lib64"
// CHECK-DEBIAN-SPARC32-LIB64: "-L[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9"
// CHECK-DEBIAN-SPARC32-LIB64: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-SPARC32-LIB64: "-L[[SYSROOT]]/usr/lib"
[SPARC] Fix windows test failure after r239154. (Hopefully) llvm-svn: 239156
2015-06-05 22:16:39 +08:00
// CHECK-DEBIAN-SPARC32-LIB64: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/64{{/|\\\\}}crtend.o"
// CHECK-DEBIAN-SPARC32-LIB64: "[[SYSROOT]]/usr/lib/gcc/sparc-linux-gnu/4.9/../../../../lib64{{/|\\\\}}crtn.o"
[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 linker paths on Debian 8 / Sparc64
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=sparc64-linux-gnu \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/debian_8_sparc64_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-SPARC64 %s
// CHECK-DEBIAN-SPARC64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
[SPARC] Fix windows test failure after r239154. (Hopefully) llvm-svn: 239156
2015-06-05 22:16:39 +08:00
// CHECK-DEBIAN-SPARC64: "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../../sparc64-linux-gnu{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-SPARC64: "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../../sparc64-linux-gnu{{/|\\\\}}crti.o"
// CHECK-DEBIAN-SPARC64: "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9{{/|\\\\}}crtbegin.o"
[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-DEBIAN-SPARC64: "-L[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9"
// CHECK-DEBIAN-SPARC64: "-L[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../../sparc64-linux-gnu"
// CHECK-DEBIAN-SPARC64: "-L[[SYSROOT]]/lib/sparc64-linux-gnu"
// CHECK-DEBIAN-SPARC64: "-L[[SYSROOT]]/lib/../lib64"
// CHECK-DEBIAN-SPARC64: "-L[[SYSROOT]]/usr/lib/sparc64-linux-gnu"
// CHECK-DEBIAN-SPARC64: "-L[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../.."
// CHECK-DEBIAN-SPARC64: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-SPARC64: "-L[[SYSROOT]]/usr/lib"
[SPARC] Fix windows test failure after r239154. (Hopefully) llvm-svn: 239156
2015-06-05 22:16:39 +08:00
// CHECK-DEBIAN-SPARC64: "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9{{/|\\\\}}crtend.o"
// CHECK-DEBIAN-SPARC64: "[[SYSROOT]]/usr/lib/gcc/sparc64-linux-gnu/4.9/../../../sparc64-linux-gnu{{/|\\\\}}crtn.o"
[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
//
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// Test linker invocation on Android.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-androideabi -rtlib=platform \
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="" \
Android standalone toolchain support. This change adds detection of C++ headers and libraries paths when building with the standalone toolchain from Android NDK. They are in a slightly unusual place. llvm-svn: 163109
2012-09-03 17:05:50 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163088
2012-09-02 17:30:11 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-android -rtlib=platform \
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="" \
Android standalone toolchain support. This change adds detection of C++ headers and libraries paths when building with the standalone toolchain from Android NDK. They are in a slightly unusual place. llvm-svn: 163109
2012-09-03 17:05:50 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163088
2012-09-02 17:30:11 +08:00
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=aarch64-linux-android -rtlib=platform \
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="" \
Add aarch64-linux-android triple for Android. llvm-svn: 206979
2014-04-23 21:36:23 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm64-linux-android -rtlib=platform \
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="" \
[ARM64] Port remaining relevant AArch64 clang tests over to ARM64 llvm-svn: 207632
2014-04-30 18:52:05 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mipsel-linux-android -rtlib=platform \
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="" \
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mips64el-linux-android -rtlib=platform \
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="" \
[Mips] Add support for mips64el-linux-android triple. llvm-svn: 200081
2014-01-26 00:04:08 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=i686-linux-android -rtlib=platform \
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="" \
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-linux-android -rtlib=platform \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID %s
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID: "{{.*}}{{/|\\\\}}crtbegin_dynamic.o"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID: "-L[[SYSROOT]]/usr/lib"
// CHECK-ANDROID-NOT: "gcc_s"
// CHECK-ANDROID: "-lgcc"
Add -ldl for non-static libgcc in Android. According to Android ABI, we have to link with libdl.so, if we are linking with non-static libgcc. Besides, this also fixes MIPS link error of undefined references to `_Unwind_Find_FDE' and `dl_iterate_phdr'. llvm-svn: 168310
2012-11-19 20:04:11 +08:00
// CHECK-ANDROID: "-ldl"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID-NOT: "gcc_s"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID: "{{.*}}{{/|\\\\}}crtend_android.o"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-androideabi -rtlib=platform \
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="" \
Android standalone toolchain support. This change adds detection of C++ headers and libraries paths when building with the standalone toolchain from Android NDK. They are in a slightly unusual place. llvm-svn: 163109
2012-09-03 17:05:50 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163088
2012-09-02 17:30:11 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-android -rtlib=platform \
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="" \
Android standalone toolchain support. This change adds detection of C++ headers and libraries paths when building with the standalone toolchain from Android NDK. They are in a slightly unusual place. llvm-svn: 163109
2012-09-03 17:05:50 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163088
2012-09-02 17:30:11 +08:00
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=aarch64-linux-android -rtlib=platform \
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="" \
Add aarch64-linux-android triple for Android. llvm-svn: 206979
2014-04-23 21:36:23 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm64-linux-android -rtlib=platform \
[ARM64] Port remaining relevant AArch64 clang tests over to ARM64 llvm-svn: 207632
2014-04-30 18:52:05 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mipsel-linux-android -rtlib=platform \
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="" \
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mips64el-linux-android -rtlib=platform \
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="" \
[Mips] Add support for mips64el-linux-android triple. llvm-svn: 200081
2014-01-26 00:04:08 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=i686-linux-android -rtlib=platform \
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="" \
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-linux-android -rtlib=platform \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-SO %s
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID-SO: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Don't add -Bsymbolic by default on Android. -Bsymbolic is not a platform requirement and should not be added unconditionally. llvm-svn: 213126
2014-07-16 16:46:35 +08:00
// CHECK-ANDROID-SO-NOT: "-Bsymbolic"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID-SO: "{{.*}}{{/|\\\\}}crtbegin_so.o"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID-SO: "-L[[SYSROOT]]/usr/lib"
// CHECK-ANDROID-SO-NOT: "gcc_s"
// CHECK-ANDROID-SO: "-lgcc"
Add -ldl for non-static libgcc in Android. According to Android ABI, we have to link with libdl.so, if we are linking with non-static libgcc. Besides, this also fixes MIPS link error of undefined references to `_Unwind_Find_FDE' and `dl_iterate_phdr'. llvm-svn: 168310
2012-11-19 20:04:11 +08:00
// CHECK-ANDROID-SO: "-ldl"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID-SO-NOT: "gcc_s"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID-SO: "{{.*}}{{/|\\\\}}crtend_so.o"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-androideabi -rtlib=platform \
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="" \
Android standalone toolchain support. This change adds detection of C++ headers and libraries paths when building with the standalone toolchain from Android NDK. They are in a slightly unusual place. llvm-svn: 163109
2012-09-03 17:05:50 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163088
2012-09-02 17:30:11 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-android -rtlib=platform \
Android standalone toolchain support. This change adds detection of C++ headers and libraries paths when building with the standalone toolchain from Android NDK. They are in a slightly unusual place. llvm-svn: 163109
2012-09-03 17:05:50 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
Rename ANDROIDEABI to Android. Most of the code guarded with ANDROIDEABI are not ARM-specific, and having no relation with arm-eabi. Thus, it will be more natural to call this environment "Android" instead of "ANDROIDEABI". Note: We are not using ANDROID because several projects are using "-DANDROID" as the conditional compilation flag. llvm-svn: 163088
2012-09-02 17:30:11 +08:00
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=aarch64-linux-android -rtlib=platform \
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="" \
Add aarch64-linux-android triple for Android. llvm-svn: 206979
2014-04-23 21:36:23 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm64-linux-android -rtlib=platform \
[ARM64] Port remaining relevant AArch64 clang tests over to ARM64 llvm-svn: 207632
2014-04-30 18:52:05 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mipsel-linux-android -rtlib=platform \
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="" \
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mips64el-linux-android -rtlib=platform \
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="" \
[Mips] Add support for mips64el-linux-android triple. llvm-svn: 200081
2014-01-26 00:04:08 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=i686-linux-android -rtlib=platform \
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="" \
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-linux-android -rtlib=platform \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -static \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-STATIC %s
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID-STATIC: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID-STATIC: "{{.*}}{{/|\\\\}}crtbegin_static.o"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID-STATIC: "-L[[SYSROOT]]/usr/lib"
// CHECK-ANDROID-STATIC-NOT: "gcc_s"
// CHECK-ANDROID-STATIC: "-lgcc"
Add -ldl for non-static libgcc in Android. According to Android ABI, we have to link with libdl.so, if we are linking with non-static libgcc. Besides, this also fixes MIPS link error of undefined references to `_Unwind_Find_FDE' and `dl_iterate_phdr'. llvm-svn: 168310
2012-11-19 20:04:11 +08:00
// CHECK-ANDROID-STATIC-NOT: "-ldl"
Clang driver support for linking on Android. llvm-svn: 155541
2012-04-25 16:59:22 +08:00
// CHECK-ANDROID-STATIC-NOT: "gcc_s"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID-STATIC: "{{.*}}{{/|\\\\}}crtend_android.o"
Wrong crtbegin/crtend pair used for PIE on Android. Android uses the same flavour of crt*.o for PIE and non-PIE executables, and a different one for DSOs. GNU/Linux, on the other hand, uses one set of crt*.o for non-PIE executables, and another for both PIE executables and DSOs. llvm-svn: 163500
2012-09-10 18:30:12 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-androideabi -rtlib=platform \
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="" \
Wrong crtbegin/crtend pair used for PIE on Android. Android uses the same flavour of crt*.o for PIE and non-PIE executables, and a different one for DSOs. GNU/Linux, on the other hand, uses one set of crt*.o for non-PIE executables, and another for both PIE executables and DSOs. llvm-svn: 163500
2012-09-10 18:30:12 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm-linux-android -rtlib=platform \
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="" \
Wrong crtbegin/crtend pair used for PIE on Android. Android uses the same flavour of crt*.o for PIE and non-PIE executables, and a different one for DSOs. GNU/Linux, on the other hand, uses one set of crt*.o for non-PIE executables, and another for both PIE executables and DSOs. llvm-svn: 163500
2012-09-10 18:30:12 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=aarch64-linux-android -rtlib=platform \
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="" \
Add aarch64-linux-android triple for Android. llvm-svn: 206979
2014-04-23 21:36:23 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=arm64-linux-android -rtlib=platform \
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="" \
[ARM64] Port remaining relevant AArch64 clang tests over to ARM64 llvm-svn: 207632
2014-04-30 18:52:05 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mipsel-linux-android -rtlib=platform \
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="" \
Implement Adnroid MIPS toolchain support: 1. Add mipsel-linux-android to the list of valid MIPS target triples. 2. Add <gcc install path>/mips-r2 to the list of toolchain specific path prefixes if target is mipsel-linux-android. The patch reviewed by Logan Chien. llvm-svn: 165131
2012-10-04 01:46:38 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=mips64el-linux-android -rtlib=platform \
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="" \
[Mips] Add support for mips64el-linux-android triple. llvm-svn: 200081
2014-01-26 00:04:08 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=i686-linux-android -rtlib=platform \
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="" \
Improve x86 android support: * -Bsymbolic must be added for x86 as well. * Default CPU name also set to 'core2' for x86 android. Patch by Edwin Vane. llvm-svn: 167307
2012-11-03 04:41:30 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Support setting default value for -rtlib at build time This patch introduces a new cmake variable: CLANG_DEFAULT_RTLIB, thru which we can specify a default value for -rtlib (libgcc or compiler-rt) at build time, just like how we set the default C++ stdlib thru CLANG_DEFAULT_CXX_STDLIB. With these two options, we can configure clang to build binaries on Linux that have no runtime dependence on any gcc libs (libstdc++ or libgcc_s). Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22663 llvm-svn: 276848
2016-07-27 16:15:54 +08:00
// RUN: --target=x86_64-linux-android -rtlib=platform \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -pie \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PIE %s
Wrong crtbegin/crtend pair used for PIE on Android. Android uses the same flavour of crt*.o for PIE and non-PIE executables, and a different one for DSOs. GNU/Linux, on the other hand, uses one set of crt*.o for non-PIE executables, and another for both PIE executables and DSOs. llvm-svn: 163500
2012-09-10 18:30:12 +08:00
// CHECK-ANDROID-PIE: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID-PIE: "{{.*}}{{/|\\\\}}crtbegin_dynamic.o"
Wrong crtbegin/crtend pair used for PIE on Android. Android uses the same flavour of crt*.o for PIE and non-PIE executables, and a different one for DSOs. GNU/Linux, on the other hand, uses one set of crt*.o for non-PIE executables, and another for both PIE executables and DSOs. llvm-svn: 163500
2012-09-10 18:30:12 +08:00
// CHECK-ANDROID-PIE: "-L[[SYSROOT]]/usr/lib"
// CHECK-ANDROID-PIE-NOT: "gcc_s"
// CHECK-ANDROID-PIE: "-lgcc"
// CHECK-ANDROID-PIE-NOT: "gcc_s"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-ANDROID-PIE: "{{.*}}{{/|\\\\}}crtend_android.o"
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-androideabi \
Don't force -pie for Android. Summary: There is no -no-pie flag that can override this, so making it default to being on for Android means it is no longer possible to create non-PIE executables on Android. While current versions of Android support (and the most recent requires) PIE, ICS and earlier versions of Android cannot run PIE executables, so this needs to be optional. Reviewers: srhines Reviewed By: srhines Subscribers: thakis, volkalexey, cfe-commits Differential Revision: http://reviews.llvm.org/D8015 llvm-svn: 231091
2015-03-04 02:24:57 +08:00
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-android \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=aarch64-linux-android \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm64-linux-android \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mipsel-linux-android \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mips64el-linux-android \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=i686-linux-android \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-linux-android \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-NO-DEFAULT-PIE %s
// CHECK-ANDROID-NO-DEFAULT-PIE-NOT: -pie
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-androideabi \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-32 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-android \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-32 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mipsel-linux-android \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-32 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Add aarch64-linux-android triple for Android. llvm-svn: 206979
2014-04-23 21:36:23 +08:00
// RUN: --target=aarch64-linux-android \
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="" \
Add aarch64-linux-android triple for Android. llvm-svn: 206979
2014-04-23 21:36:23 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-64 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
[ARM64] Port remaining relevant AArch64 clang tests over to ARM64 llvm-svn: 207632
2014-04-30 18:52:05 +08:00
// RUN: --target=arm64-linux-android \
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="" \
[ARM64] Port remaining relevant AArch64 clang tests over to ARM64 llvm-svn: 207632
2014-04-30 18:52:05 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-64 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
[Mips] Add support for mips64el-linux-android triple. llvm-svn: 200081
2014-01-26 00:04:08 +08:00
// RUN: --target=mips64el-linux-android \
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="" \
[Mips] Add support for mips64el-linux-android triple. llvm-svn: 200081
2014-01-26 00:04:08 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-64 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --target=i686-linux-android \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-32 %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-linux-android \
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="" \
Improve x86 android support, add x86_64 android target llvm-svn: 199875
2014-01-23 17:08:32 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-64 %s
// CHECK-ANDROID-32: "-dynamic-linker" "/system/bin/linker"
// CHECK-ANDROID-64: "-dynamic-linker" "/system/bin/linker64"
Do not use "lib32" directory to create a library/object files paths when target is MIPS 32-bit. The patch reviewed by Chandler Carruth. llvm-svn: 163898
2012-09-14 19:27:24 +08:00
//
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// Test that -pthread does not add -lpthread on Android.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-androideabi -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=aarch64-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm64-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mipsel-linux-android -pthread \
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mips64el-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=i686-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-androideabi -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=aarch64-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=arm64-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mipsel-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mips64el-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=i686-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-linux-android -pthread \
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="" \
-pthread does not translate to -lpthread on Android. There is no libpthread.so, and pthread interface is implemented in libc.so. This mirrors gcc behavior. llvm-svn: 209731
2014-05-28 20:53:34 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: -shared \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD %s
// CHECK-ANDROID-PTHREAD-NOT: -lpthread
//
Fix driver warning about -pthread on Android. -pthread is no-op on Android. Suppress the unused argument warning. llvm-svn: 210253
2014-06-05 19:41:39 +08:00
// RUN: %clang -no-canonical-prefixes %t.o -### -o %t 2>&1 \
// RUN: --target=arm-linux-androideabi -pthread \
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 driver warning about -pthread on Android. -pthread is no-op on Android. Suppress the unused argument warning. llvm-svn: 210253
2014-06-05 19:41:39 +08:00
// RUN: --sysroot=%S/Inputs/basic_android_tree/sysroot \
// RUN: | FileCheck --check-prefix=CHECK-ANDROID-PTHREAD-LINK %s
// CHECK-ANDROID-PTHREAD-LINK-NOT: argument unused during compilation: '-pthread'
//
Do not use "lib32" directory to create a library/object files paths when target is MIPS 32-bit. The patch reviewed by Chandler Carruth. llvm-svn: 163898
2012-09-14 19:27:24 +08:00
// Check linker invocation on Debian 6 MIPS 32/64-bit.
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mipsel-linux-gnu \
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="" \
Do not use "lib32" directory to create a library/object files paths when target is MIPS 32-bit. The patch reviewed by Chandler Carruth. llvm-svn: 163898
2012-09-14 19:27:24 +08:00
// RUN: --sysroot=%S/Inputs/debian_6_mips_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-ML-MIPSEL %s
// CHECK-DEBIAN-ML-MIPSEL: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-ML-MIPSEL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-ML-MIPSEL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib{{/|\\\\}}crti.o"
// CHECK-DEBIAN-ML-MIPSEL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4{{/|\\\\}}crtbegin.o"
Do not use "lib32" directory to create a library/object files paths when target is MIPS 32-bit. The patch reviewed by Chandler Carruth. llvm-svn: 163898
2012-09-14 19:27:24 +08:00
// CHECK-DEBIAN-ML-MIPSEL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4"
// CHECK-DEBIAN-ML-MIPSEL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib"
// CHECK-DEBIAN-ML-MIPSEL: "-L[[SYSROOT]]/lib/../lib"
// CHECK-DEBIAN-ML-MIPSEL: "-L[[SYSROOT]]/usr/lib/../lib"
// CHECK-DEBIAN-ML-MIPSEL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/../../.."
// CHECK-DEBIAN-ML-MIPSEL: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-ML-MIPSEL: "-L[[SYSROOT]]/usr/lib"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64el-linux-gnu \
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="" \
Do not use "lib32" directory to create a library/object files paths when target is MIPS 32-bit. The patch reviewed by Chandler Carruth. llvm-svn: 163898
2012-09-14 19:27:24 +08:00
// RUN: --sysroot=%S/Inputs/debian_6_mips_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-ML-MIPS64EL %s
// CHECK-DEBIAN-ML-MIPS64EL: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-ML-MIPS64EL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib64{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-ML-MIPS64EL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib64{{/|\\\\}}crti.o"
// CHECK-DEBIAN-ML-MIPS64EL: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/64{{/|\\\\}}crtbegin.o"
Do not use "lib32" directory to create a library/object files paths when target is MIPS 32-bit. The patch reviewed by Chandler Carruth. llvm-svn: 163898
2012-09-14 19:27:24 +08:00
// CHECK-DEBIAN-ML-MIPS64EL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/64"
// CHECK-DEBIAN-ML-MIPS64EL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib64"
// CHECK-DEBIAN-ML-MIPS64EL: "-L[[SYSROOT]]/lib/../lib64"
// CHECK-DEBIAN-ML-MIPS64EL: "-L[[SYSROOT]]/usr/lib/../lib64"
// CHECK-DEBIAN-ML-MIPS64EL: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/../../.."
// CHECK-DEBIAN-ML-MIPS64EL: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-ML-MIPS64EL: "-L[[SYSROOT]]/usr/lib"
Add C/C++ header locations for the Freescale SDK. The Freescale SDK is based on OpenEmbedded, and this might be useful for other OpenEmbedded-based configurations as well. With minor modifications, patch by Tobias von Koch! llvm-svn: 164177
2012-09-19 06:25:07 +08:00
//
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=mips64el-linux-gnu -mabi=n32 \
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="" \
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// RUN: --sysroot=%S/Inputs/debian_6_mips_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-ML-MIPS64EL-N32 %s
// CHECK-DEBIAN-ML-MIPS64EL-N32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-DEBIAN-ML-MIPS64EL-N32: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib32{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-ML-MIPS64EL-N32: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib32{{/|\\\\}}crti.o"
// CHECK-DEBIAN-ML-MIPS64EL-N32: "{{.*}}/usr/lib/gcc/mipsel-linux-gnu/4.4/n32{{/|\\\\}}crtbegin.o"
Add support of MIPS n32 ABI to the Clang driver. The fix builds correct library/object files paths and passes appropriate command line options to the linker if user provides -mabi=n32 option. The patch reviewed by Rafael Espindola. llvm-svn: 166389
2012-10-21 19:44:57 +08:00
// CHECK-DEBIAN-ML-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/n32"
// CHECK-DEBIAN-ML-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/../../../../lib32"
// CHECK-DEBIAN-ML-MIPS64EL-N32: "-L[[SYSROOT]]/lib/../lib32"
// CHECK-DEBIAN-ML-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/../lib32"
// CHECK-DEBIAN-ML-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib/gcc/mipsel-linux-gnu/4.4/../../.."
// CHECK-DEBIAN-ML-MIPS64EL-N32: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-ML-MIPS64EL-N32: "-L[[SYSROOT]]/usr/lib"
//
[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: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mips64-linux-gnuabi64 -mabi=n64 \
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: --sysroot=%S/Inputs/debian_6_mips64_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-ML-MIPS64-GNUABI %s
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "{{.*}}/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../../mips64-linux-gnuabi64{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "{{.*}}/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../../mips64-linux-gnuabi64{{/|\\\\}}crti.o"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "{{.*}}/usr/lib/gcc/mips64-linux-gnuabi64/4.9{{/|\\\\}}crtbegin.o"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64-linux-gnuabi64/4.9"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../../mips64-linux-gnuabi64"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/lib/mips64-linux-gnuabi64"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/usr/lib/mips64-linux-gnuabi64"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64-linux-gnuabi64/4.9"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../.."
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "-L[[SYSROOT]]/usr/lib"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "{{.*}}/usr/lib/gcc/mips64-linux-gnuabi64/4.9{{/|\\\\}}crtend.o"
// CHECK-DEBIAN-ML-MIPS64-GNUABI: "{{.*}}/usr/lib/gcc/mips64-linux-gnuabi64/4.9/../../../mips64-linux-gnuabi64{{/|\\\\}}crtn.o"
//
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=mips64el-linux-gnuabi64 -mabi=n64 \
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: --sysroot=%S/Inputs/debian_6_mips64_tree \
// RUN: | FileCheck --check-prefix=CHECK-DEBIAN-ML-MIPS64EL-GNUABI %s
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "{{.*}}/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../../mips64el-linux-gnuabi64{{/|\\\\}}crt1.o"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "{{.*}}/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../../mips64el-linux-gnuabi64{{/|\\\\}}crti.o"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "{{.*}}/usr/lib/gcc/mips64el-linux-gnuabi64/4.9{{/|\\\\}}crtbegin.o"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64el-linux-gnuabi64/4.9"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../../mips64el-linux-gnuabi64"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/lib/mips64el-linux-gnuabi64"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/usr/lib/mips64el-linux-gnuabi64"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64el-linux-gnuabi64/4.9"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../.."
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/lib"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "-L[[SYSROOT]]/usr/lib"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "{{.*}}/usr/lib/gcc/mips64el-linux-gnuabi64/4.9{{/|\\\\}}crtend.o"
// CHECK-DEBIAN-ML-MIPS64EL-GNUABI: "{{.*}}/usr/lib/gcc/mips64el-linux-gnuabi64/4.9/../../../mips64el-linux-gnuabi64{{/|\\\\}}crtn.o"
//
Add C/C++ header locations for the Freescale SDK. The Freescale SDK is based on OpenEmbedded, and this might be useful for other OpenEmbedded-based configurations as well. With minor modifications, patch by Tobias von Koch! llvm-svn: 164177
2012-09-19 06:25:07 +08:00
// Test linker invocation for Freescale SDK (OpenEmbedded).
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=powerpc-fsl-linux \
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="" \
Add C/C++ header locations for the Freescale SDK. The Freescale SDK is based on OpenEmbedded, and this might be useful for other OpenEmbedded-based configurations as well. With minor modifications, patch by Tobias von Koch! llvm-svn: 164177
2012-09-19 06:25:07 +08:00
// RUN: --sysroot=%S/Inputs/freescale_ppc_tree \
// RUN: | FileCheck --check-prefix=CHECK-FSL-PPC %s
// CHECK-FSL-PPC: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-FSL-PPC: "-m" "elf32ppclinux"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-FSL-PPC: "{{.*}}{{/|\\\\}}crt1.o"
// CHECK-FSL-PPC: "{{.*}}{{/|\\\\}}crtbegin.o"
Add C/C++ header locations for the Freescale SDK. The Freescale SDK is based on OpenEmbedded, and this might be useful for other OpenEmbedded-based configurations as well. With minor modifications, patch by Tobias von Koch! llvm-svn: 164177
2012-09-19 06:25:07 +08:00
// CHECK-FSL-PPC: "-L[[SYSROOT]]/usr/lib"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: --target=powerpc64-fsl-linux \
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="" \
Add C/C++ header locations for the Freescale SDK. The Freescale SDK is based on OpenEmbedded, and this might be useful for other OpenEmbedded-based configurations as well. With minor modifications, patch by Tobias von Koch! llvm-svn: 164177
2012-09-19 06:25:07 +08:00
// RUN: --sysroot=%S/Inputs/freescale_ppc64_tree \
// RUN: | FileCheck --check-prefix=CHECK-FSL-PPC64 %s
// CHECK-FSL-PPC64: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-FSL-PPC64: "-m" "elf64ppc"
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-FSL-PPC64: "{{.*}}{{/|\\\\}}crt1.o"
// CHECK-FSL-PPC64: "{{.*}}{{/|\\\\}}crtbegin.o"
Add C/C++ header locations for the Freescale SDK. The Freescale SDK is based on OpenEmbedded, and this might be useful for other OpenEmbedded-based configurations as well. With minor modifications, patch by Tobias von Koch! llvm-svn: 164177
2012-09-19 06:25:07 +08:00
// CHECK-FSL-PPC64: "-L[[SYSROOT]]/usr/lib64/powerpc64-fsl-linux/4.6.2/../.."
Driver: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
//
Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// Check that crtfastmath.o is linked with -ffast-math and with -Ofast.
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: %clang --target=x86_64-unknown-linux -### %s \
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: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NOCRTFASTMATH %s
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: %clang --target=x86_64-unknown-linux -### %s -ffast-math \
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: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: %clang --target=x86_64-unknown-linux -### %s -funsafe-math-optimizations\
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: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: %clang --target=x86_64-unknown-linux -### %s -Ofast\
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 logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -### %s -Ofast -O3\
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 logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NOCRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -### %s -O3 -Ofast\
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 logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: %clang --target=x86_64-unknown-linux -### %s -ffast-math -fno-fast-math \
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: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NOCRTFASTMATH %s
Fix an logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: %clang --target=x86_64-unknown-linux -### %s -Ofast -fno-fast-math \
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 logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -### %s -Ofast -fno-unsafe-math-optimizations \
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 logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -### %s -fno-fast-math -Ofast \
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 logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
// RUN: %clang --target=x86_64-unknown-linux -### %s -fno-unsafe-math-optimizations -Ofast \
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 logic error in the clang driver preventing crtfastmath.o from linking when -Ofast is used without -ffast-math In gcc using -Ofast forces linking of crtfastmath.o. In the current clang crtfastmath.o is only linked when -ffast-math/-funsafe-math-optimizations passed. It can lead to performance issues, when using only -Ofast without explicit -ffast-math (I faced with it). My patch fixes inconsistency with gcc behaviour and also introduces few tests on it. Patch by Zinovy Nis! Differential Revision: http://llvm-reviews.chandlerc.com/D3114 llvm-svn: 204742
2014-03-26 02:02:07 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-CRTFASTMATH %s
Driver: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
// We don't have crtfastmath.o in the i386 tree, use it to check that file
// detection works.
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: %clang --target=i386-unknown-linux -### %s -ffast-math \
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: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>&1 \
// RUN: | FileCheck --check-prefix=CHECK-NOCRTFASTMATH %s
Accept both / and \\ to fix the windows bots. llvm-svn: 184790
2013-06-25 06:07:15 +08:00
// CHECK-CRTFASTMATH: usr/lib/gcc/x86_64-unknown-linux/4.6.0{{/|\\\\}}crtfastmath.o
Driver: Link crtfastmath.o if it's available and -ffast-math is specified. crtfastmath.o contains routines to set the floating point flags to a faster, unsafe mode. Linking it in speeds up code dealing with denormals significantly (PR14024). For now this is only enabled on linux where I can test it and crtfastmath.o is widely available. We may want to provide a similar file with compiler-rt eventually and/or enable it on other platforms too. llvm-svn: 165240
2012-10-05 03:42:20 +08:00
// CHECK-NOCRTFASTMATH-NOT: crtfastmath.o
When we're compiling with -pg make sure to link with gcrt1.o on linux. Be sure to do this always, this matches the behavior for the gcc driver. Fixes PR16251. Based on a patch by Qiao Yang. llvm-svn: 183591
2013-06-08 07:25:01 +08:00
// Check that we link in gcrt1.o when compiling with -pg
Update two options to my proposed syntax for user-facing driver options: -gcc-toolchain foo -> --gcc-toolchain=foo -target foo -> --target=foo I've added legacy aliases for the original spellings. I've updated the canonical tests to check both spellings, and switched all of the -gcc-toolchain usages elsewhere in the test suite to use the new one. I've updated some of the usages of -target to the new syntax, but will finish that in a separate entirely mechanical change once I'm sure this won't get rolled back for some reason (It touches a *huge* number of RUN lines in the test suite unsurprisingly). A nice result is that the three most common flags I end up using when doing cross compiles are all now consistent: --target=, --sysroot=, and --gcc-toolchain=. llvm-svn: 184408
2013-06-20 17:42:40 +08:00
// RUN: %clang -pg --target=x86_64-unknown-linux -### %s \
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="" \
When we're compiling with -pg make sure to link with gcrt1.o on linux. Be sure to do this always, this matches the behavior for the gcc driver. Fixes PR16251. Based on a patch by Qiao Yang. llvm-svn: 183591
2013-06-08 07:25:01 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>& 1 \
// RUN: | FileCheck --check-prefix=CHECK-PG %s
// CHECK-PG: gcrt1.o
Forward -u to the linker on gnutools toolchains Summary: The BSDs and Darwin all forward the whole 'u' group, but gcc only forwards -u so far as I can tell. I only forward -u, since that's a minimal change, and many people object to magically recognizing and forwarding linker arguments. Reviewers: chandlerc, joerg Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4304 llvm-svn: 211756
2014-06-26 09:08:54 +08:00
// GCC forwards -u to the linker.
// RUN: %clang -u asdf --target=x86_64-unknown-linux -### %s \
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="" \
Forward -u to the linker on gnutools toolchains Summary: The BSDs and Darwin all forward the whole 'u' group, but gcc only forwards -u so far as I can tell. I only forward -u, since that's a minimal change, and many people object to magically recognizing and forwarding linker arguments. Reviewers: chandlerc, joerg Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D4304 llvm-svn: 211756
2014-06-26 09:08:54 +08:00
// RUN: --sysroot=%S/Inputs/basic_linux_tree 2>& 1 \
// RUN: | FileCheck --check-prefix=CHECK-u %s
// CHECK-u: "-u" "asdf"
For the --be8 flag, check explicitly for pre-v7 / pre-v6m cores. Those used the old Big Endian support on ARM and don't need flags. Refactor the logic in a separate common function, which also looks at -march. Add corresponding logic for the Linux toolchain. llvm-svn: 227393
2015-01-29 07:30:39 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=armeb-unknown-linux \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-ARMEB %s
// CHECK-ARMEB: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-ARMEB-NOT: "--be8"
This patch fixes target linker emulation for ARM 32 big endian. llvm-svn: 272402
2016-06-11 00:09:20 +08:00
// CHECK-ARMEB: "-m" "armelfb_linux_eabi"
For the --be8 flag, check explicitly for pre-v7 / pre-v6m cores. Those used the old Big Endian support on ARM and don't need flags. Refactor the logic in a separate common function, which also looks at -march. Add corresponding logic for the Linux toolchain. llvm-svn: 227393
2015-01-29 07:30:39 +08:00
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=armebv7-unknown-linux \
// RUN: --gcc-toolchain="" \
// RUN: --sysroot=%S/Inputs/basic_linux_tree \
// RUN: | FileCheck --check-prefix=CHECK-ARMV7EB %s
// CHECK-ARMV7EB: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-ARMV7EB: "--be8"
This patch fixes target linker emulation for ARM 32 big endian. llvm-svn: 272402
2016-06-11 00:09:20 +08:00
// CHECK-ARMV7EB: "-m" "armelfb_linux_eabi"
Start adding support for Musl. The two patches together enable clang to support targets like "x86_64-pc-linux-musl" and build binaries against musl-libc instead of glibc. This make it easy for clang to work on some musl-based systems like Alpine Linux and certain flavors of Gentoo. Patch by Lei Zhang. llvm-svn: 272662
2016-06-14 20:47:24 +08:00
// Check dynamic-linker for musl-libc
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=i386-pc-linux-musl \
Add a few Musl related tests that already pass. Patch by Lei Zhang. llvm-svn: 272825
2016-06-16 04:02:22 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MUSL-X86 %s
Start adding support for Musl. The two patches together enable clang to support targets like "x86_64-pc-linux-musl" and build binaries against musl-libc instead of glibc. This make it easy for clang to work on some musl-based systems like Alpine Linux and certain flavors of Gentoo. Patch by Lei Zhang. llvm-svn: 272662
2016-06-14 20:47:24 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-pc-linux-musl \
Add a few Musl related tests that already pass. Patch by Lei Zhang. llvm-svn: 272825
2016-06-16 04:02:22 +08:00
// RUN: | FileCheck --check-prefix=CHECK-MUSL-X86_64 %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=mips-pc-linux-musl \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-MIPS %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=mipsel-pc-linux-musl \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-MIPSEL %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=mips64-pc-linux-musl \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-MIPS64 %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=mips64el-pc-linux-musl \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-MIPS64EL %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc-pc-linux-musl \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-PPC %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=powerpc64-pc-linux-musl \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-PPC64 %s
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273735
2016-06-25 05:35:06 +08:00
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=thumb-pc-linux-musleabi \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARM %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=thumb-pc-linux-musleabihf \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Fix two bugs for musl-libc on ARM Bug 1: triples like armv7-pc-linux-musl use the wrong linker name ld-musl-armv7.so.1; the right name should be ld-musl-arm.so.1, disregarding the subarch field. Bug 2: when compiler option -mhard-float is used, we should use the "hardfloat" linker, no matter whether the triple itself mentions "hardfloat". Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22904 llvm-svn: 277985
2016-08-08 16:27:36 +08:00
// RUN: --target=thumbv7-pc-linux-musleabi -mhard-float \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273735
2016-06-25 05:35:06 +08:00
// RUN: --target=thumbeb-pc-linux-musleabi \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMEB %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=thumbeb-pc-linux-musleabihf \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Fix two bugs for musl-libc on ARM Bug 1: triples like armv7-pc-linux-musl use the wrong linker name ld-musl-armv7.so.1; the right name should be ld-musl-arm.so.1, disregarding the subarch field. Bug 2: when compiler option -mhard-float is used, we should use the "hardfloat" linker, no matter whether the triple itself mentions "hardfloat". Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22904 llvm-svn: 277985
2016-08-08 16:27:36 +08:00
// RUN: --target=thumbv7eb-pc-linux-musleabi -mhard-float \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273735
2016-06-25 05:35:06 +08:00
// RUN: --target=arm-pc-linux-musleabi \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARM %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=arm-pc-linux-musleabihf \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Fix two bugs for musl-libc on ARM Bug 1: triples like armv7-pc-linux-musl use the wrong linker name ld-musl-armv7.so.1; the right name should be ld-musl-arm.so.1, disregarding the subarch field. Bug 2: when compiler option -mhard-float is used, we should use the "hardfloat" linker, no matter whether the triple itself mentions "hardfloat". Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22904 llvm-svn: 277985
2016-08-08 16:27:36 +08:00
// RUN: --target=armv7-pc-linux-musleabi -mhard-float \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273735
2016-06-25 05:35:06 +08:00
// RUN: --target=armeb-pc-linux-musleabi \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMEB %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=armeb-pc-linux-musleabihf \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Fix two bugs for musl-libc on ARM Bug 1: triples like armv7-pc-linux-musl use the wrong linker name ld-musl-armv7.so.1; the right name should be ld-musl-arm.so.1, disregarding the subarch field. Bug 2: when compiler option -mhard-float is used, we should use the "hardfloat" linker, no matter whether the triple itself mentions "hardfloat". Patch by Lei Zhang! Differential Revision: https://reviews.llvm.org/D22904 llvm-svn: 277985
2016-08-08 16:27:36 +08:00
// RUN: --target=armv7eb-pc-linux-musleabi -mhard-float \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-ARMEBHF %s
// RUN: %clang %s -### -o %t.o 2>&1 \
Add support for musl-libc on ARM Linux. Patch by Lei Zhang! llvm-svn: 273735
2016-06-25 05:35:06 +08:00
// RUN: --target=aarch64-pc-linux-musleabi \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-AARCH64 %s
// RUN: %clang %s -### -o %t.o 2>&1 \
// RUN: --target=aarch64_be-pc-linux-musleabi \
// RUN: | FileCheck --check-prefix=CHECK-MUSL-AARCH64_BE %s
// CHECK-MUSL-X86: "-dynamic-linker" "/lib/ld-musl-i386.so.1"
// CHECK-MUSL-X86_64: "-dynamic-linker" "/lib/ld-musl-x86_64.so.1"
// CHECK-MUSL-MIPS: "-dynamic-linker" "/lib/ld-musl-mips.so.1"
// CHECK-MUSL-MIPSEL: "-dynamic-linker" "/lib/ld-musl-mipsel.so.1"
// CHECK-MUSL-MIPS64: "-dynamic-linker" "/lib/ld-musl-mips64.so.1"
// CHECK-MUSL-MIPS64EL: "-dynamic-linker" "/lib/ld-musl-mips64el.so.1"
// CHECK-MUSL-PPC: "-dynamic-linker" "/lib/ld-musl-powerpc.so.1"
// CHECK-MUSL-PPC64: "-dynamic-linker" "/lib/ld-musl-powerpc64.so.1"
// CHECK-MUSL-ARM: "-dynamic-linker" "/lib/ld-musl-arm.so.1"
// CHECK-MUSL-ARMHF: "-dynamic-linker" "/lib/ld-musl-armhf.so.1"
// CHECK-MUSL-ARMEB: "-dynamic-linker" "/lib/ld-musl-armeb.so.1"
// CHECK-MUSL-ARMEBHF: "-dynamic-linker" "/lib/ld-musl-armebhf.so.1"
// CHECK-MUSL-AARCH64: "-dynamic-linker" "/lib/ld-musl-aarch64.so.1"
// CHECK-MUSL-AARCH64_BE: "-dynamic-linker" "/lib/ld-musl-aarch64_be.so.1"
[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
// Check whether multilib gcc install works fine on Gentoo with gcc-config
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnu -rtlib=platform \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-LD-GENTOO %s
// CHECK-LD-GENTOO-NOT: warning:
// CHECK-LD-GENTOO: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-GENTOO: "--eh-frame-hdr"
// CHECK-LD-GENTOO: "-m" "elf_x86_64"
// CHECK-LD-GENTOO: "-dynamic-linker"
[Driver] Attempt to fix new linux-ld tests on Windows (broken by r289436) llvm-svn: 289440
2016-12-13 00:04:37 +08:00
// CHECK-LD-GENTOO: "{{.*}}/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3{{/|\\\\}}crtbegin.o"
[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
// CHECK-LD-GENTOO: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3"
// CHECK-LD-GENTOO: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/lib"
// CHECK-LD-GENTOO: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../.."
// CHECK-LD-GENTOO: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
// CHECK-LD-GENTOO: "-lc"
// CHECK-LD-GENTOO: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=i686-unknown-linux-gnu -rtlib=platform \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-LD-GENTOO-32 %s
// CHECK-LD-GENTOO-32-NOT: warning:
// CHECK-LD-GENTOO-32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-GENTOO-32: "--eh-frame-hdr"
// CHECK-LD-GENTOO-32: "-m" "elf_i386"
// CHECK-LD-GENTOO-32: "-dynamic-linker"
[Driver] Attempt to fix new linux-ld tests on Windows (broken by r289436) llvm-svn: 289440
2016-12-13 00:04:37 +08:00
// CHECK-LD-GENTOO-32: "{{.*}}/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32{{/|\\\\}}crtbegin.o"
[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
// CHECK-LD-GENTOO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/32"
// CHECK-LD-GENTOO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/lib"
// CHECK-LD-GENTOO-32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../.."
// CHECK-LD-GENTOO-32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
// CHECK-LD-GENTOO-32: "-lc"
// CHECK-LD-GENTOO-32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
// RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
// RUN: --target=x86_64-unknown-linux-gnux32 -rtlib=platform \
// RUN: --sysroot=%S/Inputs/gentoo_linux_gcc_multi_version_tree \
// RUN: --gcc-toolchain="" \
// RUN: | FileCheck --check-prefix=CHECK-LD-GENTOO-X32 %s
// CHECK-LD-GENTOO-X32-NOT: warning:
// CHECK-LD-GENTOO-X32: "{{.*}}ld{{(.exe)?}}" "--sysroot=[[SYSROOT:[^"]+]]"
// CHECK-LD-GENTOO-X32: "--eh-frame-hdr"
// CHECK-LD-GENTOO-X32: "-m" "elf32_x86_64"
// CHECK-LD-GENTOO-X32: "-dynamic-linker"
[Driver] Attempt to fix new linux-ld tests on Windows (broken by r289436) llvm-svn: 289440
2016-12-13 00:04:37 +08:00
// CHECK-LD-GENTOO-X32: "{{.*}}/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/x32{{/|\\\\}}crtbegin.o"
[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
// CHECK-LD-GENTOO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/x32"
// CHECK-LD-GENTOO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/lib"
// CHECK-LD-GENTOO-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../.."
// CHECK-LD-GENTOO-X32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
// CHECK-LD-GENTOO-X32: "-lc"
// CHECK-LD-GENTOO-X32: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"