| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch makes asan instrument memory accesses with unusual sizes (e.g. 5 bytes or 10 bytes), e.g. long double or
packed structures.
Instrumentation is done with two 1-byte checks
(first and last bytes) and if the error is found
__asan_report_load_n(addr, real_size) or
__asan_report_store_n(addr, real_size)
is called.
Also, call these two new functions in memset/memcpy
instrumentation.
asan-rt part will follow.
llvm-svn: 175507
|
|
|
|
|
|
| |
long double will require a more general solution
llvm-svn: 175442
|
|
|
|
|
|
| |
https://code.google.com/p/address-sanitizer/issues/detail?id=151
llvm-svn: 175266
|
|
|
|
| |
llvm-svn: 175033
|
|
|
|
|
|
| |
may get mapped at 0x100000000+ and thus may interleave with the shadow.
llvm-svn: 174964
|
|
|
|
|
|
| |
roughly 5% speedup. Since this is an ABI change, bump the asan ABI version by renaming __asan_init to __asan_init_v1. llvm part, compiler-rt part will follow
llvm-svn: 174957
|
|
|
|
|
|
|
|
|
|
| |
This flag makes asan use a small (<2G) offset for 64-bit asan shadow mapping.
On x86_64 this saves us a register, thus achieving ~2/3 of the
zero-base-offset's benefits in both performance and code size.
Thanks Jakub Jelinek for the idea.
llvm-svn: 174886
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/12867368>"
This reverts r171041. This was a nice idea that didn't work out well.
Clang warnings need to be associated with warning groups so that they can
be selectively disabled, promoted to errors, etc. This simplistic patch didn't
allow for that. Enhancing it to provide some way for the backend to specify
a front-end warning type seems like overkill for the few uses of this, at
least for now.
llvm-svn: 174748
|
|
|
|
|
|
|
| |
Fixed set-but-not-used warnings.
Reviewer: gribozavr
llvm-svn: 173810
|
|
|
|
|
|
|
|
| |
It is way too slow. Change the default option value to 0.
Always do exact shadow propagation for unsigned ICmp with constants, it is
cheap (under 1% cpu time) and required for correctness.
llvm-svn: 173682
|
|
|
|
|
|
| |
Broken tests.
llvm-svn: 173679
|
|
|
|
|
|
| |
50% slowdown on one of the specs.
llvm-svn: 173678
|
|
|
|
| |
llvm-svn: 173453
|
|
|
|
|
|
|
|
| |
Only for integers, pointers, and vectors of those. No floats.
Instrumentation seems very heavy, and may need to be replaced
with some approximation in the future.
llvm-svn: 173452
|
|
|
|
| |
llvm-svn: 173338
|
|
|
|
|
|
| |
the redzone)
llvm-svn: 173335
|
|
|
|
|
|
| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55975 for details
llvm-svn: 173258
|
|
|
|
|
|
| |
when removing one attribute. This further encapsulates the use of the attributes.
llvm-svn: 173214
|
|
|
|
| |
llvm-svn: 173156
|
|
|
|
|
|
| |
Volatile bitfields can cause valid stores of uninitialized bits.
llvm-svn: 173153
|
|
|
|
|
|
| |
includes.
llvm-svn: 172891
|
|
|
|
| |
llvm-svn: 172813
|
|
|
|
| |
llvm-svn: 172806
|
|
|
|
|
|
| |
the values of shadow scale and offset to the runtime
llvm-svn: 172709
|
|
|
|
|
|
| |
passes. Add test for non-default mapping scale and offset. No functionality change
llvm-svn: 172610
|
|
|
|
|
|
| |
Also improve test coveration of the handling of relational comparisons.
llvm-svn: 172539
|
|
|
|
|
|
|
|
|
| |
This fixes va_start/va_copy of a va_list field which happens to not
be laid out at a 16-byte boundary.
Differential Revision: http://llvm-reviews.chandlerc.com/D276
llvm-svn: 172128
|
|
|
|
|
|
|
|
|
|
| |
code that includes Intrinsics.gen directly.
This never showed up in my testing because the old Intrinsics.gen was
still kicking around in the make build system and was correct there. =[
Thankfully, some of the bots to clean rebuilds and that caught this.
llvm-svn: 171373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
llvm-svn: 171366
|
|
|
|
|
|
|
|
|
|
| |
utils/sort_includes.py script.
Most of these are updating the new R600 target and fixing up a few
regressions that have creeped in since the last time I sorted the
includes.
llvm-svn: 171362
|
|
|
|
|
|
|
|
|
| |
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171253
|
|
|
|
| |
llvm-svn: 171183
|
|
|
|
|
|
| |
it describes one of 'interesting' allocas. Assume that allocas can go through casts and phi-nodes before apperaring as llvm.lifetime arguments
llvm-svn: 171153
|
|
|
|
|
|
|
| |
Origin alignment is as high as the alignment of the corresponding application
location, but never less than 4.
llvm-svn: 171110
|
|
|
|
| |
llvm-svn: 171109
|
|
|
|
|
|
|
| |
VectorType::getInteger() can not be used with them, because pointer size
depends on the target.
llvm-svn: 171070
|
|
|
|
| |
llvm-svn: 171069
|
|
|
|
|
|
| |
consistency
llvm-svn: 171061
|
|
|
|
| |
llvm-svn: 171060
|
|
|
|
|
|
|
|
|
| |
When the backend is used from clang, it should produce proper diagnostics
instead of just printing messages to errs(). Other clients may also want to
register their own error handlers with the LLVMContext, and the same handler
should work for warnings in the same way as the existing emitError methods.
llvm-svn: 171041
|
|
|
|
| |
llvm-svn: 170902
|
|
|
|
| |
llvm-svn: 170883
|
|
|
|
| |
llvm-svn: 170544
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes adds shadow and origin propagation for unknown intrinsics
by examining the arguments and ModRef behaviour. For now, only 3 classes
of intrinsics are handled:
- those that look like simple SIMD store
- those that look like simple SIMD load
- those that don't have memory effects and look like arithmetic/logic/whatever
operation on simple types.
llvm-svn: 170530
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170502
|
|
|
|
| |
llvm-svn: 170404
|
|
|
|
| |
llvm-svn: 170347
|
|
|
|
| |
llvm-svn: 170203
|
|
|
|
|
|
| |
Origin address is always 4 byte aligned, and the access type is always i32.
llvm-svn: 170199
|
|
|
|
|
|
|
|
| |
This change moves the code for default shadow propagaition (handleShadowOr)
and origin tracking (setOriginForNaryOp) into a new builder-like class. Also
gets rid of handleShadowOrBinary.
llvm-svn: 170192
|