summaryrefslogtreecommitdiff
path: root/test/ExecutionEngine
diff options
context:
space:
mode:
authorDavid Majnemer <david.majnemer@gmail.com>2013-11-07 22:15:53 +0000
committerDavid Majnemer <david.majnemer@gmail.com>2013-11-07 22:15:53 +0000
commit0ab20588523b59a65a4a29d47184a41443fa9337 (patch)
treee497851cb16eb365bdce1806199408264e48388f /test/ExecutionEngine
parent5ebdcd29b641ef3e6d32c2921c8cef8906ebdfcd (diff)
downloadllvm-0ab20588523b59a65a4a29d47184a41443fa9337.tar.gz
llvm-0ab20588523b59a65a4a29d47184a41443fa9337.tar.bz2
llvm-0ab20588523b59a65a4a29d47184a41443fa9337.tar.xz
IR: Do not canonicalize constant GEPs into an out-of-bounds array access
Summary: Consider a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 0) If we proceeded to GEP the aforementioned object by 8, would form a GEP of: i8* getelementptr ({ [2 x i8], i32, i8, [3 x i8] }* @main.c, i32 0, i32 0, i64 8) Note that we would go through the first array member, causing an out-of-bounds accesses. This is problematic because we might get fooled if we are trying to evaluate loads using this GEP, for example, based off of an object with a constant initializer where the array is zero. This fixes PR17732. Reviewers: nicholas, chandlerc, void Reviewed By: void CC: llvm-commits, echristo, void, aemerson Differential Revision: http://llvm-reviews.chandlerc.com/D2093 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194220 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/ExecutionEngine')
0 files changed, 0 insertions, 0 deletions