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/cuda-no-stack-protector.cu

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

24 lines
787 B
Plaintext
Raw Normal View History

[CUDA] Don't pass -stack-protector to NVPTX compilations. We can't support stack-protector on NVPTX because NVPTX doesn't expose a stack to the compiler! Fixes PR32009. llvm-svn: 295609
2017-02-20 03:05:32 +08:00
// Check that -stack-protector doesn't get passed down to device-side
// compilation.
//
// REQUIRES: clang-driver
//
// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 \
// RUN: -fstack-protector-all %s 2>&1 | \
// RUN: FileCheck %s
//
// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 \
// RUN: -fstack-protector-strong %s 2>&1 | \
// RUN: FileCheck %s
//
// RUN: %clang -### -target x86_64-linux-gnu -c --cuda-gpu-arch=sm_20 \
// RUN: -fstack-protector %s 2>&1 | \
// RUN: FileCheck %s
//
// CHECK-NOT: error: unsupported option '-fstack-protector
// CHECK-DAG: "-fcuda-is-device"
// CHECK-NOT: "-stack-protector"
// CHECK-NOT: "-stack-protector-buffer-size"
[ADT] Normalize empty triple components LLVM triple normalization is handling "unknown" and empty components differently; for example given "x86_64-unknown-linux-gnu" and "x86_64-linux-gnu" which should be equivalent, triple normalization returns "x86_64-unknown-linux-gnu" and "x86_64--linux-gnu". autoconf's config.sub returns "x86_64-unknown-linux-gnu" for both "x86_64-linux-gnu" and "x86_64-unknown-linux-gnu". This changes the triple normalization to behave the same way, replacing empty triple components with "unknown". This addresses PR37129. Differential Revision: https://reviews.llvm.org/D50219 llvm-svn: 339294
2018-08-09 06:23:57 +08:00
// CHECK-DAG: "-triple" "x86_64-unknown-linux-gnu"
[CUDA] Don't pass -stack-protector to NVPTX compilations. We can't support stack-protector on NVPTX because NVPTX doesn't expose a stack to the compiler! Fixes PR32009. llvm-svn: 295609
2017-02-20 03:05:32 +08:00
// CHECK: "-stack-protector"