maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/sanitize-trap.c

31 lines
1.1 KiB
C
Raw Normal View History

Fix hexagon test failure. llvm-svn: 240106
2015-06-19 08:39:59 +08:00
// RUN: %clang_cc1 -triple x86_64-pc-linux-gnu -emit-llvm -o - %s -fsanitize=signed-integer-overflow,integer-divide-by-zero -fsanitize-trap=integer-divide-by-zero | FileCheck %s
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
int f(int x, int y) {
// CHECK: %[[B1:.*]] = icmp ne i32 %[[D:.*]], 0
// CHECK: %[[B2:.*]] = icmp ne i32 %[[N:.*]], -2147483648
// CHECK: %[[B3:.*]] = icmp ne i32 %[[D]], -1
// CHECK: %[[B4:.*]] = or i1 %[[B2]], %[[B3]]
// CHECK: br i1 %[[B1]], label %[[L1:[0-9a-z_.]*]], label %[[L2:[0-9a-z_.]*]]
Fix test for Release builds, the label form is <label>:14, not <label>14. llvm-svn: 246391
2015-08-31 01:46:43 +08:00
// {{^|:}} used to match both Debug form of the captured label
Make test resistant to false matches of numbered (unnamed) labels inside other numbers. In release builds labels are numbers. Matching just the number may result in false matches where the label is contained in other numbers, such as 14 inside [114 x i8]. A stricter match requiring start of line or > character before the label avoids these false matches. llvm-svn: 246385
2015-08-30 23:24:46 +08:00
// cont:
// and Release form
Fix test for Release builds, the label form is <label>:14, not <label>14. llvm-svn: 246391
2015-08-31 01:46:43 +08:00
// ; <label>:14
Make test resistant to false matches of numbered (unnamed) labels inside other numbers. In release builds labels are numbers. Matching just the number may result in false matches where the label is contained in other numbers, such as 14 inside [114 x i8]. A stricter match requiring start of line or > character before the label avoids these false matches. llvm-svn: 246385
2015-08-30 23:24:46 +08:00
// But avoids false matches inside other numbers such as [114 x i8].
Fix test for Release builds, the label form is <label>:14, not <label>14. llvm-svn: 246391
2015-08-31 01:46:43 +08:00
// CHECK: {{^|:}}[[L2]]
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
// CHECK-NEXT: call void @llvm.trap()
// CHECK-NEXT: unreachable
Fix test for Release builds, the label form is <label>:14, not <label>14. llvm-svn: 246391
2015-08-31 01:46:43 +08:00
// CHECK: {{^|:}}[[L1]]
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
// CHECK-NEXT: br i1 %[[B4]], label %[[L3:[0-9a-z_.]*]], label %[[L4:[0-9a-z_.]*]]
Fix test for Release builds, the label form is <label>:14, not <label>14. llvm-svn: 246391
2015-08-31 01:46:43 +08:00
// CHECK: {{^|:}}[[L4]]
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
// CHECK-NEXT: zext
// CHECK-NEXT: zext
// CHECK-NEXT: __ubsan_handle_divrem_overflow
Fix test for Release builds, the label form is <label>:14, not <label>14. llvm-svn: 246391
2015-08-31 01:46:43 +08:00
// CHECK: {{^|:}}[[L3]]
Introduce -fsanitize-trap= flag. This flag controls whether a given sanitizer traps upon detecting an error. It currently only supports UBSan. The existing flag -fsanitize-undefined-trap-on-error has been made an alias of -fsanitize-trap=undefined. This change also cleans up some awkward behavior around the combination of -fsanitize-trap=undefined and -fsanitize=undefined. Previously we would reject command lines containing the combination of these two flags, as -fsanitize=vptr is not compatible with trapping. This required the creation of -fsanitize=undefined-trap, which excluded -fsanitize=vptr (and -fsanitize=function, but this seems like an oversight). Now, -fsanitize=undefined is an alias for -fsanitize=undefined-trap, and if -fsanitize-trap=undefined is specified, we treat -fsanitize=vptr as an "unsupported" flag, which means that we error out if the flag is specified explicitly, but implicitly disable it if the flag was implied by -fsanitize=undefined. Differential Revision: http://reviews.llvm.org/D10464 llvm-svn: 240105
2015-06-19 07:59:22 +08:00
// CHECK-NEXT: sdiv i32 %[[N]], %[[D]]
return x / y;
}