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/windows-cross.c

78 lines
6.8 KiB
C
Raw Normal View History

Driver: only inject libstdc++ paths when needed on CrossWindows When building with libc++ don't bother with injecting the libstdc++ search paths into the linker search path. This will make it easier to switch between ld and lld. llvm-svn: 302184
2017-05-05 03:18:21 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=ld -stdlib=libstdc++ -rtlib=compiler-rt -o /dev/null %s 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-BASIC-LIBCXX
// CHECK-BASIC-LIBCXX: armv7-windows-itanium-ld" "--sysroot={{.*}}/Inputs/Windows/ARM/8.1" "-m" "thumb2pe" "-Bdynamic" "--entry" "mainCRTStartup" "--allow-multiple-definition" "-o" "{{[^"]*}}" "{{[^"]*}}.o" "-lmsvcrt"
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %s/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=ld -rtlib=compiler-rt -stdlib=libstdc++ -o /dev/null %s 2>&1 \
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
// RUN: | FileCheck %s --check-prefix CHECK-RTLIB
Driver: only inject libstdc++ paths when needed on CrossWindows When building with libc++ don't bother with injecting the libstdc++ search paths into the linker search path. This will make it easier to switch between ld and lld. llvm-svn: 302184
2017-05-05 03:18:21 +08:00
// CHECK-RTLIB: armv7-windows-itanium-ld" "--sysroot={{.*}}/Inputs/Windows/ARM/8.1" "-m" "thumb2pe" "-Bdynamic" "--entry" "mainCRTStartup" "--allow-multiple-definition" "-o" "{{[^"]*}}" "{{.*}}.o" "-lmsvcrt" "{{.*[\\/]}}clang_rt.builtins-arm.lib"
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=ld -rtlib=compiler-rt -stdlib=libc++ -o /dev/null %s 2>&1 \
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
// RUN: | FileCheck %s --check-prefix CHECK-C-LIBCXX
Toolchains: remove crtbegin on xwindows crtbegin is not really a proper windows support thing. This was duplicated when the toolchain was initially built. If the injection of crtbegin is needed, it can be done via the `/include` directive. Furthermore, since `-fPIC` doesnt make sense on PE/COFF, crtbegin and crtbeginS dont really need to be different. llvm-svn: 299800
2017-04-08 04:47:06 +08:00
// CHECK-C-LIBCXX: armv7-windows-itanium-ld" "--sysroot={{.*}}/Inputs/Windows/ARM/8.1" "-m" "thumb2pe" "-Bdynamic" "--entry" "mainCRTStartup" "--allow-multiple-definition" "-o" "{{[^"]*}}" "{{.*}}.o" "-lmsvcrt" "{{.*[\\/]}}clang_rt.builtins-arm.lib"
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clangxx -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=ld -rtlib=compiler-rt -stdlib=libc++ -o /dev/null %s 2>&1 \
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
// RUN: | FileCheck %s --check-prefix CHECK-LIBCXX
Toolchains: remove crtbegin on xwindows crtbegin is not really a proper windows support thing. This was duplicated when the toolchain was initially built. If the injection of crtbegin is needed, it can be done via the `/include` directive. Furthermore, since `-fPIC` doesnt make sense on PE/COFF, crtbegin and crtbeginS dont really need to be different. llvm-svn: 299800
2017-04-08 04:47:06 +08:00
// CHECK-LIBCXX: armv7-windows-itanium-ld" "--sysroot={{.*}}/Inputs/Windows/ARM/8.1" "-m" "thumb2pe" "-Bdynamic" "--entry" "mainCRTStartup" "--allow-multiple-definition" "-o" "{{[^"]*}}" "{{.*}}.o" "-lc++" "-lmsvcrt" "{{.*[\\/]}}clang_rt.builtins-arm.lib"
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=ld -shared -rtlib=compiler-rt -stdlib=libc++ -o shared.dll %s 2>&1 \
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
// RUN: | FileCheck %s --check-prefix CHECK-SHARED
Toolchains: remove crtbegin on xwindows crtbegin is not really a proper windows support thing. This was duplicated when the toolchain was initially built. If the injection of crtbegin is needed, it can be done via the `/include` directive. Furthermore, since `-fPIC` doesnt make sense on PE/COFF, crtbegin and crtbeginS dont really need to be different. llvm-svn: 299800
2017-04-08 04:47:06 +08:00
// CHECK-SHARED: armv7-windows-itanium-ld" "--sysroot={{.*}}/Inputs/Windows/ARM/8.1" "-m" "thumb2pe" "-shared" "-Bdynamic" "--enable-auto-image-base" "--entry" "_DllMainCRTStartup" "--allow-multiple-definition" "-o" "shared.dll" "--out-implib" "shared.lib" "{{.*}}.o" "-lmsvcrt" "{{.*[\\/]}}clang_rt.builtins-arm.lib"
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %s/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=ld -shared -rtlib=compiler-rt -stdlib=libc++ -nostartfiles -o shared.dll %s 2>&1 \
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
// RUN: | FileCheck %s --check-prefix CHECK-NOSTARTFILES
Revert "Driver: use the canonical static library naming" This breaks chromium and its unclear if this is actually a modern convention. This reverts SVN r280169. llvm-svn: 280281
2016-09-01 03:27:07 +08:00
// CHECK-NOSTARTFILES: armv7-windows-itanium-ld" "--sysroot={{.*}}/Inputs/Windows/ARM/8.1" "-m" "thumb2pe" "-shared" "-Bdynamic" "--enable-auto-image-base" "--entry" "_DllMainCRTStartup" "--allow-multiple-definition" "-o" "shared.dll" "--out-implib" "shared.lib" "{{.*}}.o" "-lmsvcrt" "{{.*[\\/]}}clang_rt.builtins-arm.lib"
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
Fix tests with CLANG_DEFAULT_LINKER I originally requested this to be tested in D25263 but in the end forgot to make sure that it was done. Differential Revision: https://reviews.llvm.org/D28289 llvm-svn: 291389
2017-01-08 18:04:07 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=ld -shared -rtlib=compiler-rt -stdlib=libc++ -nostartfiles -nodefaultlibs -o shared.dll %s 2>&1 \
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
// RUN: | FileCheck %s --check-prefix CHECK-STANDALONE
Driver: remove a stray s that propagated in cross-windows The option is '--allow-multiple-definition' not '--allow-multiple-definitions'. llvm-svn: 220760
2014-10-28 11:15:02 +08:00
// CHECK-STANDALONE: armv7-windows-itanium-ld" "--sysroot={{.*}}/Inputs/Windows/ARM/8.1" "-m" "thumb2pe" "-shared" "-Bdynamic" "--enable-auto-image-base" "--entry" "_DllMainCRTStartup" "--allow-multiple-definition" "-o" "shared.dll" "--out-implib" "shared.lib" "{{.*}}.o"
Driver: add CrossWindowsToolChain This is a very basic toolchain. It supports cross-compiling Windows (primarily inspired by the WoA target). It is meant to use clang with the LLVM IAS and a binutils ld-compatible interface for the linker (eventually to be lld). It does not perform any "standard" GCC lookup, nor does it perform any special adjustments given that it is expected to be used in an environment where the user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK. The primary runtime library is expected to be compiler-rt and the C++ implementation to be libc++. It also expects that a sysroot has been setup given the usual Unix semantics (standard C headers in /usr/include, all the import libraries available in /usr/lib). It also expects that an entry point stub is present in /usr/lib (crtbegin.obj for executables, crtbeginS.obj for shared libraries). The entry point stub is responsible for running any GNU constructors. llvm-svn: 220546
2014-10-24 11:13:37 +08:00
Driver: support -fuse-ld= on cross windows Update the linker selection to support the `-fuse-ld=` option for selecting a linker. llvm-svn: 251493
2015-10-28 12:45:58 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=lld-link2 -shared -o shared.dll -x c++ %s 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-FUSE-LD
Driver: tweak CrossWindows sanitizer support Indicate support for ASAN on the CrossWindows toolchain. Although this is insufficient, this at least permits the handling of the driver flag. llvm-svn: 251598
2015-10-29 11:36:38 +08:00
Driver: support -fuse-ld= on cross windows Update the linker selection to support the `-fuse-ld=` option for selecting a linker. llvm-svn: 251493
2015-10-28 12:45:58 +08:00
// CHECK-FUSE-LD: "{{.*}}lld-link2"
Driver: tweak CrossWindows sanitizer support Indicate support for ASAN on the CrossWindows toolchain. Although this is insufficient, this at least permits the handling of the driver flag. llvm-svn: 251598
2015-10-29 11:36:38 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=lld-link2 -shared -o shared.dll -fsanitize=address -x c++ %s 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-SANITIZE-ADDRESS
// CHECK-SANITIZE-ADDRESS: "-fsanitize=address"
Driver: CrossWindows sanitizers link support Add the required libraries to the linker invocation when building with sanitizers. llvm-svn: 251600
2015-10-29 11:36:45 +08:00
// CHECK-SANITIZE-ADDRESS: "{{.*}}clang_rt.asan_dll_thunk-arm.lib"
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=lld-link2 -o test.exe -fsanitize=address -x c++ %s 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-SANITIZE-ADDRESS-EXE
// CHECK-SANITIZE-ADDRESS-EXE: "-fsanitize=address"
// CHECK-SANITIZE-ADDRESS-EXE: "{{.*}}clang_rt.asan_dynamic-arm.lib" "{{.*}}clang_rt.asan_dynamic_runtime_thunk-arm.lib" "--undefined" "__asan_seh_interceptor"
// RUN: %clang -### -target i686-windows-itanium -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=lld-link2 -o test.exe -fsanitize=address -x c++ %s 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-SANITIZE-ADDRESS-EXE-X86
// CHECK-SANITIZE-ADDRESS-EXE-X86: "-fsanitize=address"
Reland r311836 - [Driver] Use arch type to find compiler-rt libraries (on Linux) Use llvm::Triple::getArchTypeName() when looking for compiler-rt libraries, rather than the exact arch string from the triple. This is more correct as it matches the values used when building compiler-rt (builtin-config-ix.cmake) which are the subset of the values allowed in triples. For example, this fixes an issue when the compiler set for i686-pc-linux-gnu triple would not find an i386 compiler-rt library, while this is the exact arch that is detected by compiler-rt. The same applies to any other i?86 variant allowed by LLVM. This also makes the special case for MSVC unnecessary, since now i386 will be used reliably for all 32-bit x86 variants. Differential Revision: https://reviews.llvm.org/D26796 llvm-svn: 311923
2017-08-29 04:29:52 +08:00
// CHECK-SANITIZE-ADDRESS-EXE-X86: "{{.*}}clang_rt.asan_dynamic-i386.lib" "{{.*}}clang_rt.asan_dynamic_runtime_thunk-i386.lib" "--undefined" "___asan_seh_interceptor"
Driver: tweak CrossWindows sanitizer support Indicate support for ASAN on the CrossWindows toolchain. Although this is insufficient, this at least permits the handling of the driver flag. llvm-svn: 251598
2015-10-29 11:36:38 +08:00
// RUN: %clang -### -target armv7-windows-itanium --sysroot %S/Inputs/Windows/ARM/8.1 -B %S/Inputs/Windows/ARM/8.1/usr/bin -fuse-ld=lld-link2 -shared -o shared.dll -fsanitize=tsan -x c++ %s 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-SANITIZE-TSAN
test: fix overzealous match Accidentally made the test too strict. llvm-svn: 251603
2015-10-29 11:52:14 +08:00
// CHECK-SANITIZE-TSAN: error: unsupported argument 'tsan' to option 'fsanitize='
Driver: tweak CrossWindows sanitizer support Indicate support for ASAN on the CrossWindows toolchain. Although this is insufficient, this at least permits the handling of the driver flag. llvm-svn: 251598
2015-10-29 11:36:38 +08:00
// CHECK-SANITIZE-TSAN-NOT: "-fsanitize={{.*}}"
Driver: introduce and use `-isystem-after` for cross-windows This mirrors the many other -i*after options to insert a new system search directory at the end of the search path. This makes it possible to actually inject a search path after the resource dir. This option is similar in spirit to the /imsvc option in the clang-cl driver. This is needed to properly use the driver for Windows targets where the clang headers wrap some of the system headers. This concept is actually useful on other targets (e.g. Linux) and would be really easy to support on the core toolchain. llvm-svn: 273016
2016-06-18 01:23:16 +08:00
// RUN: %clang -### -target armv7-windows-itanium -isystem-after "Windows Kits/10/Include/10.0.10586.0/ucrt" -isystem-after "Windows Kits/10/Include/10.0.10586.0/um" -isystem-after "Windows Kits/10/Include/10.0.10586.0/shared" -c %s -o /dev/null 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-ISYSTEM-AFTER
Make test less sensitive to the resource directory. Same tactic as linux-header-search.cpp and android-ndk-standalone.cpp. llvm-svn: 273158
2016-06-20 22:33:49 +08:00
// CHECK-ISYSTEM-AFTER: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-ISYSTEM-AFTER: "-internal-isystem" "[[RESOURCE_DIR]]{{(/|\\\\)}}include"
test: support / and \ as directory separators Windows uses \ as the directory separator and this causes the tests to fail on Windows. llvm-svn: 273036
2016-06-18 03:59:01 +08:00
// CHECK-ISYSTEM-AFTER: "-internal-isystem" "Windows Kits{{[/\\]}}10{{[/\\]}}Include{{[/\\]}}10.0.10586.0{{[/\\]}}ucrt"
// CHECK-ISYSTEM-AFTER: "-internal-isystem" "Windows Kits{{[/\\]}}10{{[/\\]}}Include{{[/\\]}}10.0.10586.0{{[/\\]}}um"
// CHECK-ISYSTEM-AFTER: "-internal-isystem" "Windows Kits{{[/\\]}}10{{[/\\]}}Include{{[/\\]}}10.0.10586.0{{[/\\]}}shared"
Driver: introduce and use `-isystem-after` for cross-windows This mirrors the many other -i*after options to insert a new system search directory at the end of the search path. This makes it possible to actually inject a search path after the resource dir. This option is similar in spirit to the /imsvc option in the clang-cl driver. This is needed to properly use the driver for Windows targets where the clang headers wrap some of the system headers. This concept is actually useful on other targets (e.g. Linux) and would be really easy to support on the core toolchain. llvm-svn: 273016
2016-06-18 01:23:16 +08:00
Driver: honor -nostdinc and -isystem-after on CrossWindows This changes CrossWindows to look for -nostdinc instead of -nostdlibinc. In addition, fixes a bug where -isystem-after options would be dropped when called with -nostdinc. Patch by Dave Lee! llvm-svn: 306829
2017-06-30 23:15:38 +08:00
// RUN: %clang -### -target armv7-windows-itanium -nostdinc -isystem-after "Windows Kits/10/Include/10.0.10586.0/ucrt" -c %s -o /dev/null 2>&1 \
// RUN: | FileCheck %s --check-prefix CHECK-NOSTDINC-ISYSTEM-AFTER
// CHECK-NOSTDINC-ISYSTEM-AFTER: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
// CHECK-NOSTDINC-ISYSTEM-AFTER-NOT: "-internal-isystem" "[[RESOURCE_DIR]]{{(/|\\\\)}}include"
// CHECK-NOSTDINC-ISYSTEM-AFTER: "-internal-isystem" "Windows Kits{{[/\\]}}10{{[/\\]}}Include{{[/\\]}}10.0.10586.0{{[/\\]}}ucrt"