summaryrefslogtreecommitdiff
path: root/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll
diff options
context:
space:
mode:
authorKostya Serebryany <kcc@google.com>2012-02-06 22:48:56 +0000
committerKostya Serebryany <kcc@google.com>2012-02-06 22:48:56 +0000
commit0ca032b03dc3a862670461651b3a950d1f14991b (patch)
treebb9ecc9629dede3d3e0a6f141a440a98399da14c /test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll
parent44ebf8b0331cb3a994a8df16fb63fdcdbc37d927 (diff)
downloadllvm-0ca032b03dc3a862670461651b3a950d1f14991b.tar.gz
llvm-0ca032b03dc3a862670461651b3a950d1f14991b.tar.bz2
llvm-0ca032b03dc3a862670461651b3a950d1f14991b.tar.xz
The patch resolves the conflict between AddressSanitizer and load widening (GVN).
The problem initially reported by Mozilla folks (http://code.google.com/p/address-sanitizer/issues/detail?id=20), but it also prevents us from enabling LLVM bootstrap with AddressSanitizer. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149925 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll')
-rw-r--r--test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll43
1 files changed, 43 insertions, 0 deletions
diff --git a/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll b/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll
new file mode 100644
index 0000000000..e7a5713632
--- /dev/null
+++ b/test/Instrumentation/AddressSanitizer/asan-vs-gvn.ll
@@ -0,0 +1,43 @@
+; RUN: opt < %s -basicaa -gvn -asan -S | FileCheck %s
+; ASAN conflicts with load widening iff the widened load accesses data out of bounds
+; (while the original unwidened loads do not).
+; http://code.google.com/p/address-sanitizer/issues/detail?id=20#c1
+
+
+; 32-bit little endian target.
+target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128-n8:16:32"
+
+%struct_of_7_bytes_4_aligned = type { i32, i8, i8, i8}
+
+@f = global %struct_of_7_bytes_4_aligned zeroinitializer, align 4
+
+; Accessing bytes 4 and 6, not ok to widen to i32 if address_safety is set.
+
+define i32 @test_widening_bad(i8* %P) nounwind ssp noredzone address_safety {
+entry:
+ %tmp = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 1), align 4
+ %conv = zext i8 %tmp to i32
+ %tmp1 = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 3), align 1
+ %conv2 = zext i8 %tmp1 to i32
+ %add = add nsw i32 %conv, %conv2
+ ret i32 %add
+; CHECK: @test_widening_bad
+; CHECK: __asan_report_load1
+; CHECK: __asan_report_load1
+; CHECK-ret i32
+}
+
+;; Accessing byets 4 and 5. Ok to widen to i16.
+
+define i32 @test_widening_ok(i8* %P) nounwind ssp noredzone address_safety {
+entry:
+ %tmp = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 1), align 4
+ %conv = zext i8 %tmp to i32
+ %tmp1 = load i8* getelementptr inbounds (%struct_of_7_bytes_4_aligned* @f, i64 0, i32 2), align 1
+ %conv2 = zext i8 %tmp1 to i32
+ %add = add nsw i32 %conv, %conv2
+ ret i32 %add
+; CHECK: @test_widening_ok
+; CHECK: __asan_report_load1
+; CHECK-ret i32
+}