aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
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
commitbd4fef4a8939db18f39b108e19097b25e2c7c47a (patch)
tree1e3b5b9b445da349af4c3b9d297f633c5fe3d220 /clang/lib/Frontend/CompilerInvocation.cpp
parentb805c68f4d0a1ff0362ff41db7b670d4609178d8 (diff)
downloadllvm-bd4fef4a8939db18f39b108e19097b25e2c7c47a.zip
llvm-bd4fef4a8939db18f39b108e19097b25e2c7c47a.tar.gz
llvm-bd4fef4a8939db18f39b108e19097b25e2c7c47a.tar.bz2
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 llvm-svn: 194220
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions