#
b050c7fb |
| 11-Apr-2017 |
Diana Picus <diana.picus@linaro.org> |
Revert "Turn some C-style vararg into variadic templates"
This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008
ll
Revert "Turn some C-style vararg into variadic templates"
This reverts commit r299925 because it broke the buildbots. See e.g. http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008
llvm-svn: 299928
show more ...
|
#
5fd75fb7 |
| 11-Apr-2017 |
Serge Guelton <sguelton@quarkslab.com> |
Turn some C-style vararg into variadic templates
Module::getOrInsertFunction is using C-style vararg instead of variadic templates.
From a user prospective, it forces the use of an annoying nullptr
Turn some C-style vararg into variadic templates
Module::getOrInsertFunction is using C-style vararg instead of variadic templates.
From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues.
llvm-svn: 299925
show more ...
|
#
db11fdfd |
| 06-Apr-2017 |
Mehdi Amini <mehdi.amini@apple.com> |
Revert "Turn some C-style vararg into variadic templates"
This reverts commit r299699, the examples needs to be updated.
llvm-svn: 299702
|
#
579540a8 |
| 06-Apr-2017 |
Mehdi Amini <mehdi.amini@apple.com> |
Turn some C-style vararg into variadic templates
Module::getOrInsertFunction is using C-style vararg instead of variadic templates.
From a user prospective, it forces the use of an annoying nullptr
Turn some C-style vararg into variadic templates
Module::getOrInsertFunction is using C-style vararg instead of variadic templates.
From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments. The variadic template is an obvious solution to both issues.
Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu>
Differential Revision: https://reviews.llvm.org/D31070
llvm-svn: 299699
show more ...
|
#
b518054b |
| 21-Mar-2017 |
Reid Kleckner <rnk@google.com> |
Rename AttributeSet to AttributeList
Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttr
Rename AttributeSet to AttributeList
Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
show more ...
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3 |
|
#
8eb1a485 |
| 15-Feb-2017 |
Arnold Schwaighofer <aschwaighofer@apple.com> |
ThreadSanitizer: don't track swifterror memory addresses
They are register promoted by ISel and so it makes no sense to treat them as memory.
Inserting calls to the thread sanitizer would also gene
ThreadSanitizer: don't track swifterror memory addresses
They are register promoted by ISel and so it makes no sense to treat them as memory.
Inserting calls to the thread sanitizer would also generate invalid IR.
You would hit:
"swifterror value can only be loaded and stored from, or as a swifterror argument!"
llvm-svn: 295215
show more ...
|
Revision tags: llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
#
ddfdba3b |
| 14-Nov-2016 |
Kuba Brecka <kuba.brecka@gmail.com> |
[tsan] Add support for C++ exceptions into TSan (call __tsan_func_exit during unwinding), LLVM part
This adds support for TSan C++ exception handling, where we need to add extra calls to __tsan_func
[tsan] Add support for C++ exceptions into TSan (call __tsan_func_exit during unwinding), LLVM part
This adds support for TSan C++ exception handling, where we need to add extra calls to __tsan_func_exit when a function is exitted via exception mechanisms. Otherwise the shadow stack gets corrupted (leaked). This patch moves and enhances the existing implementation of EscapeEnumerator that finds all possible function exit points, and adds extra EH cleanup blocks where needed.
Differential Revision: https://reviews.llvm.org/D26177
llvm-svn: 286893
show more ...
|
#
3c437378 |
| 11-Nov-2016 |
Anna Zaks <ganna@apple.com> |
[tsan][llvm] Implement the function attribute to disable TSan checking at run time
This implements a function annotation that disables TSan checking for the function at run time. The benefit over at
[tsan][llvm] Implement the function attribute to disable TSan checking at run time
This implements a function annotation that disables TSan checking for the function at run time. The benefit over attribute((no_sanitize("thread"))) is that the accesses within the callees will also be suppressed.
The motivation for this attribute is a guarantee given by the objective C language that the calls to the reference count decrement and object deallocation will be synchronized. To model this properly, we would need to intercept all ref count decrement calls (which are very common in ObjC due to use of ARC) and also every single message send. Instead, we propose to just ignore all accesses made from within dealloc at run time. The main downside is that this still does not introduce any synchronization, which means we might still report false positives if the code that relies on this synchronization is not executed from within dealloc. However, we have not seen this in practice so far and think these cases will be very rare.
Differential Revision: https://reviews.llvm.org/D25858
llvm-svn: 286663
show more ...
|
#
44e875ad |
| 07-Nov-2016 |
Kuba Brecka <kuba.brecka@gmail.com> |
[tsan] Cast floating-point types correctly when instrumenting atomic accesses, LLVM part
Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. T
[tsan] Cast floating-point types correctly when instrumenting atomic accesses, LLVM part
Although rare, atomic accesses to floating-point types seem to be valid, i.e. `%a = load atomic float ...`. The TSan instrumentation pass however tries to emit inttoptr, which is incorrect, we should use a bitcast here. Anyway, IRBuilder already has a convenient helper function for this.
Differential Revision: https://reviews.llvm.org/D26266
llvm-svn: 286135
show more ...
|
#
117296c0 |
| 01-Oct-2016 |
Mehdi Amini <mehdi.amini@apple.com> |
Use StringRef in Pass/PassManager APIs (NFC)
llvm-svn: 283004
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2 |
|
#
b03fd12c |
| 17-Aug-2016 |
Justin Bogner <mail@justinbogner.com> |
Replace "fallthrough" comments with LLVM_FALLTHROUGH
This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.
llvm
Replace "fallthrough" comments with LLVM_FALLTHROUGH
This is a mechanical change of comments in switches like fallthrough, fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.
llvm-svn: 278902
show more ...
|
Revision tags: llvmorg-3.9.0-rc1 |
|
#
57faf2d2 |
| 19-Jul-2016 |
Vedant Kumar <vsk@apple.com> |
[tsan] Don't instrument __llvm_gcov_global_state_pred or __llvm_gcda*
r274801 did not go far enough to allow gcov+tsan to cooperate. With this commit it's possible to run the following code without
[tsan] Don't instrument __llvm_gcov_global_state_pred or __llvm_gcda*
r274801 did not go far enough to allow gcov+tsan to cooperate. With this commit it's possible to run the following code without false positives:
std::thread T1(fib), T2(fib); T1.join(); T2.join();
llvm-svn: 276015
show more ...
|
#
0fdffd37 |
| 07-Jul-2016 |
Vedant Kumar <vsk@apple.com> |
[tsan] Try harder to not instrument gcov counters
GCOVProfiler::emitProfileArcs() can create many variables with names starting with "__llvm_gcov_ctr", so llvm appends a numeric suffix to most of th
[tsan] Try harder to not instrument gcov counters
GCOVProfiler::emitProfileArcs() can create many variables with names starting with "__llvm_gcov_ctr", so llvm appends a numeric suffix to most of them. Teach tsan about this.
llvm-svn: 274801
show more ...
|
#
d7708773 |
| 24-Jun-2016 |
David Majnemer <david.majnemer@gmail.com> |
Switch more loops to be range-based
This makes the code a little more concise, no functional change is intended.
llvm-svn: 273644
|
#
644d9d3a |
| 22-Jun-2016 |
Anna Zaks <ganna@apple.com> |
[asan] Do not instrument pointers with address space attributes
Do not instrument pointers with address space attributes since we cannot track them anyway. Instrumenting them results in false positi
[asan] Do not instrument pointers with address space attributes
Do not instrument pointers with address space attributes since we cannot track them anyway. Instrumenting them results in false positives in ASan and a compiler crash in TSan. (The compiler should not crash in any case, but that's a different problem.)
llvm-svn: 273339
show more ...
|
#
0222adbc |
| 20-Jun-2016 |
Vedant Kumar <vsk@apple.com> |
[tsan] Do not instrument accesses to the gcov counters array
There is a known intended race here. This is a follow-up to r264805, which disabled tsan instrumentation for updates to instrprof counter
[tsan] Do not instrument accesses to the gcov counters array
There is a known intended race here. This is a follow-up to r264805, which disabled tsan instrumentation for updates to instrprof counters. For more background on this please see the discussion in D18164.
llvm-svn: 273202
show more ...
|
#
3feda222 |
| 18-Jun-2016 |
Marcin Koscielnicki <koriakin@0x04.net> |
[sanitizers] Disable target-specific lowering of string functions.
CodeGen has hooks that allow targets to emit specialized code instead of calls to memcmp, memchr, strcpy, stpcpy, strcmp, strlen, s
[sanitizers] Disable target-specific lowering of string functions.
CodeGen has hooks that allow targets to emit specialized code instead of calls to memcmp, memchr, strcpy, stpcpy, strcmp, strlen, strnlen. When ASan/MSan/TSan/ESan is in use, this sidesteps its interceptors, resulting in uninstrumented memory accesses. To avoid that, make these sanitizers mark the calls as nobuiltin.
Differential Revision: http://reviews.llvm.org/D19781
llvm-svn: 273083
show more ...
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
#
4fb78518 |
| 07-Apr-2016 |
Benjamin Kramer <benny.kra@googlemail.com> |
Make helper functions static. NFC.
llvm-svn: 265653
|
#
800f87a8 |
| 06-Apr-2016 |
JF Bastien <jfb@google.com> |
NFC: make AtomicOrdering an enum class
Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 b
NFC: make AtomicOrdering an enum class
Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open.
The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum).
This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang.
As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync.
Reviewers: jyknight, reames
Subscribers: jyknight, llvm-commits
Differential Revision: http://reviews.llvm.org/D18775
llvm-svn: 265602
show more ...
|
#
1a470b6f |
| 29-Mar-2016 |
Anna Zaks <ganna@apple.com> |
[tsan] Do not instrument reads/writes to instruction profile counters.
We have known races on profile counters, which can be reproduced by enabling -fsanitize=thread and -fprofile-instr-generate sim
[tsan] Do not instrument reads/writes to instruction profile counters.
We have known races on profile counters, which can be reproduced by enabling -fsanitize=thread and -fprofile-instr-generate simultaneously on a multi-threaded program. This patch avoids reporting those races by not instrumenting the reads and writes coming from the instruction profiler.
llvm-svn: 264805
show more ...
|
#
c1efa64c |
| 07-Mar-2016 |
Anna Zaks <ganna@apple.com> |
[tsan] Add support for pointer typed atomic stores, loads, and cmpxchg
TSan instrumentation functions for atomic stores, loads, and cmpxchg work on integer value types. This patch adds casts before
[tsan] Add support for pointer typed atomic stores, loads, and cmpxchg
TSan instrumentation functions for atomic stores, loads, and cmpxchg work on integer value types. This patch adds casts before calling TSan instrumentation functions in cases where the value is a pointer.
Differential Revision: http://reviews.llvm.org/D17833
llvm-svn: 262876
show more ...
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3 |
|
#
dfb655fe |
| 15-Aug-2015 |
Yaron Keren <yaron.keren@gmail.com> |
Try to appease VS 2015 warnings from http://reviews.llvm.org/D11890 ByteSize and BitSize should not be size_t but unsigned, considering
1) They are at most 2^16 and 2^19, respectively. 2) BitSize is
Try to appease VS 2015 warnings from http://reviews.llvm.org/D11890 ByteSize and BitSize should not be size_t but unsigned, considering
1) They are at most 2^16 and 2^19, respectively. 2) BitSize is an argument to Type::getIntNTy which takes unsigned.
Also, use the correct utostr instead itostr and cache the string result.
Thanks to James Touton for reporting this!
llvm-svn: 245167
show more ...
|
Revision tags: studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1 |
|
#
ff6409d0 |
| 18-May-2015 |
David Blaikie <dblaikie@gmail.com> |
Simplify IRBuilder::CreateCall* by using ArrayRef+initializer_list/braced init only
llvm-svn: 237624
|
Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1 |
|
#
2d4ae9f0 |
| 07-May-2015 |
Ismail Pazarbasi <ismail.pazarbasi@gmail.com> |
TSan: Use `createSanitizerCtor` to create ctor, and call `__tsan_init`
Reviewers: kcc, dvyukov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8779
llvm-svn: 236778
|
#
198d6d53 |
| 06-Apr-2015 |
Ismail Pazarbasi <ismail.pazarbasi@gmail.com> |
Move `checkInterfaceFunction` to ModuleUtils
Summary: Instead of making a local copy of `checkInterfaceFunction` for each sanitizer, move the function in a common place.
Reviewers: kcc, samsonov
S
Move `checkInterfaceFunction` to ModuleUtils
Summary: Instead of making a local copy of `checkInterfaceFunction` for each sanitizer, move the function in a common place.
Reviewers: kcc, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8775
llvm-svn: 234220
show more ...
|