| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209790
|
|
|
|
|
|
|
|
|
| |
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209789
|
|
|
|
|
|
|
|
| |
An address only use of an extract element of a load can be simplified to a
load. Without this the result of the extract element is spilled to the
stack so that an address is available.
llvm-svn: 209788
|
|
|
|
|
|
|
| |
These are confusing enough since the order swaps,
so give them more useful names.
llvm-svn: 209787
|
|
|
|
|
|
| |
deduce any packs that are expanded by both expansions.
llvm-svn: 209786
|
|
|
|
|
|
| |
libc++) to stop working. And tests
llvm-svn: 209785
|
|
|
|
| |
llvm-svn: 209784
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D2802
llvm-svn: 209783
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D2803
llvm-svn: 209782
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D3887
llvm-svn: 209781
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime.
Don't assume that dynamically initialized globals are all initialized from
_GLOBAL__<module_name>I_ function. Instead, scan the llvm.global_ctors and
insert poison/unpoison calls to each function there.
Patch by Nico Weber!
llvm-svn: 209780
|
|
|
|
|
|
|
| |
Patch by: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D3888
llvm-svn: 209779
|
|
|
|
|
|
|
|
| |
And fixed typos in the ASan readme.
Differential Revision: http://reviews.llvm.org/D3927
llvm-svn: 209778
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a function to combine two 32-bit integers into a 64-bit integer.
There are no calls to this function yet, although a subsequent change
will add some in LLDB.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D3941
llvm-svn: 209777
|
|
|
|
|
|
|
|
| |
overflows.""
This reverts commit r209762, bringing back r209746. It was not responsible for the libc++ build failure
llvm-svn: 209776
|
|
|
|
|
|
|
|
| |
This reverts commit r209755.
it was the real cause of the libc++ build failure.
llvm-svn: 209775
|
|
|
|
|
|
| |
local contexts. Also includes some minor refactoring.
llvm-svn: 209774
|
|
|
|
| |
llvm-svn: 209773
|
|
|
|
|
|
|
|
|
| |
No test because no in-tree targets change the bitwidth of the
setcc type depending on the bitwidth of the compared type.
Patch by Ke Bai
llvm-svn: 209771
|
|
|
|
| |
llvm-svn: 209770
|
|
|
|
|
|
| |
(fixes PR19431 - http://llvm.org/bugs/show_bug.cgi?id=19431)
llvm-svn: 209769
|
|
|
|
| |
llvm-svn: 209768
|
|
|
|
|
|
|
|
| |
Until now all CUDA-specific attributes were represented with
CXCursor_UnexposedAttr; now they are actually implemented, including the Python
bindings.
llvm-svn: 209767
|
|
|
|
|
|
|
|
| |
I opened a discussion on cfe-commits. Ideally we've got a few things
that need to happen. CompilerRT should probably have blacklists tests.
Asan should probably not depend on that specific field.
llvm-svn: 209766
|
|
|
|
|
|
|
|
|
|
| |
Since the continuation block of the if statement is emitted within the
condition scope this had the undesirable effect of creating a line table
entry at the end of the then or else statement, a line that may have never
been executed.
PR19864 / rdar://problem/17052973
llvm-svn: 209764
|
|
|
|
| |
llvm-svn: 209763
|
|
|
|
|
|
|
|
|
| |
This reverts commit r209746.
It looks it is causing a crash while building libcxx. I am trying to get a
reduced testcase.
llvm-svn: 209762
|
|
|
|
| |
llvm-svn: 209761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, DataTypes.h would #define a variety of symbols any time
they weren't already defined. However, some versions of Visual
Studio do provide the appropriate headers, so if those headers are
included after DataTypes.h, it can lead to macro redefinition
warnings.
The fix is to include the appropriate headers if they exist, and
only #define the symbols if the required header does not exist.
Patch by Zachary Turner!
---
The big change here is that we no longer have our own stdint.h
typedefs because now all supported toolchains have stdint.h.
Hooray!
llvm-svn: 209760
|
|
|
|
|
|
|
|
|
|
| |
This matches gcc's behavior. It also seems natural given that aliases
contain other properties that govern how it is accessed (linkage,
visibility, dll storage).
Clang still has to be updated to expose this feature to C.
llvm-svn: 209759
|
|
|
|
|
|
|
| |
now deprecated, ObjC containers instead of crashing.
// rdar://16859666
llvm-svn: 209758
|
|
|
|
|
|
|
|
|
|
| |
The refactoring makes suppressions more flexible
and allow to suppress based on arbitrary number of stacks.
In particular it fixes:
https://code.google.com/p/thread-sanitizer/issues/detail?id=64
"Make it possible to suppress deadlock reports by any stack (not just first)"
llvm-svn: 209757
|
|
|
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D3934 for more details.
This is only the CMakeLists.txt portion of that change.
Change by Zachary Turner.
llvm-svn: 209756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently LLVM will generally merge GEPs. This allows backends to use more
complex addressing modes. In some cases this is not happening because there
is PHI inbetween the two GEPs:
GEP1--\
|-->PHI1-->GEP3
GEP2--/
This patch checks to see if GEP1 and GEP2 are similiar enough that they can be
cloned (GEP12) in GEP3's BB, allowing GEP->GEP merging (GEP123):
GEP1--\ --\ --\
|-->PHI1-->GEP3 ==> |-->PHI2->GEP12->GEP3 == > |-->PHI2->GEP123
GEP2--/ --/ --/
This also breaks certain use chains that are preventing GEP->GEP merges that the
the existing instcombine would merge otherwise.
Tests included.
llvm-svn: 209755
|
|
|
|
| |
llvm-svn: 209754
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ CL-option --polly-tile-sizes=<int,...,int>
The i'th value is used as a tile size for dimension i, if
there is no i'th value, the value of --polly-default-tile-size is
used
+ CL-option --polly-default-tile-size=int
Used if no tile size is given for a dimension i
+ 3 Simple testcases
llvm-svn: 209753
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disables exception handling in LLDB, using appropriate compiler
flags depending on the platform. This is consistent with the build
of LLVM, should improve performance, and also removes a substantial number
of warnings from the Windows build.
See http://reviews.llvm.org/D3929 for more details.
Change by Zachary Turner
llvm-svn: 209752
|
|
|
|
|
|
|
| |
in Objective-C container declarations (but not
in their definitions. // rdar://10414277
llvm-svn: 209751
|
|
|
|
| |
llvm-svn: 209750
|
|
|
|
|
|
|
|
|
|
| |
This fixes a number of trivial warnings in the Windows build. This is part of a larger effort to make the Windows build warning-free.
See http://reviews.llvm.org/D3914 for more details.
Change by Zachary Turner
llvm-svn: 209749
|
|
|
|
|
|
|
|
|
|
| |
value is live"
This reverts r208640 (I've just XFAILed the test) because it broke ppc64/Linux
self-hosting. Because nearly every regression test triggers a segfault, I hope
this will be easy to fix.
llvm-svn: 209747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements two things:
1. If we know one number is positive and another is negative, we return true as
signed addition of two opposite signed numbers will never overflow.
2. Implemented TODO : If one of the operands only has one non-zero bit, and if
the other operand has a known-zero bit in a more significant place than it
(not including the sign bit) the ripple may go up to and fill the zero, but
won't change the sign. e.x - (x & ~4) + 1
We make sure that we are ignoring 0 at MSB.
Patch by Suyog Sarda.
llvm-svn: 209746
|
|
|
|
|
|
|
|
|
| |
This reverts commit r209638 because it broke self-hosting on ppc64/Linux. (the
Clang-compiled TableGen would segfault because it jumped to an invalid address
from within _ZNK4llvm17ManagedStaticBase21RegisterManagedStaticEPFPvvEPFvS1_E
(which is within the command-line parameter registration process)).
llvm-svn: 209745
|
|
|
|
|
|
| |
64-bit atomics make porting of asan to 32-bits platforms problematic.
llvm-svn: 209744
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 209743
|
|
|
|
|
|
| |
it is set.
llvm-svn: 209742
|
|
|
|
|
|
|
| |
Patch from: GuanHong Liu
Differential Revision: http://reviews.llvm.org/D3886
llvm-svn: 209741
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3885
llvm-svn: 209740
|
|
|
|
| |
llvm-svn: 209739
|
|
|
|
| |
llvm-svn: 209738
|