llvm-svn: 169141

llvm-svn: 169140

llvm-svn: 169139

llvm-svn: 169138

This formatting library will be used by a stand-alone clang-format tool
and can also be used when writing other refactorings.

Manuel's original design document:
https://docs.google.com/a/google.com/document/d/1gpckL2U_6QuU9YW2L1ABsc4Fcogn5UngKk7fE5dDOoA/edit

The library can already successfully format itself.

Review: http://llvm-reviews.chandlerc.com/D80
llvm-svn: 169137

Forwarding a fix for a crasher in the demangler.

llvm-svn: 169136

Teach the jump threading optimization to stop scanning the basic block when calculating the cost after passing the threshold.

llvm-svn: 169135

llvm-svn: 169134

AKA: Recompile *ALL* the source code!

This one went much better. No manual edits here. I spot-checked for
silliness and grep-checked for really broken edits and everything seemed
good. It all still compiles. Yell if you see something that looks goofy.

llvm-svn: 169133

Kind of important when prepping the include/... tree version of the sort
changes.

llvm-svn: 169132

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 169130

llvm-svn: 169129

llvm-svn: 169128

We now switch to the newly released isl 0.11. This adds a couple of bug fixes
on top of the recent update.

llvm-svn: 169127

llvm-svn: 169126

standards.

I am a terrible Python programmer. Patches more the welcome. Please tell
me how this should look if it should look differently. It's just a tiny
little script so it didn't make sense to go through pre-commit review,
especially as someone who actually knows python may want to just rip it
apart and do it The Right Way.

I will be preparing a commit shortly that uses this script to
canonicalize *all* of the #include lines in LLVM. Really, all of them.

llvm-svn: 169125

llvm-svn: 169124

llvm-svn: 169123

llvm-svn: 169122

llvm-svn: 169121

The partitioning logic attempted to handle uses of an alloca with an
offset starting before the alloca so long as the use had some overlap
with the alloca itself. However, there was a bug where we tested
'(uint64_t)Offset >= AllocSize' without first checking whether 'Offset'
was positive. As a consequence, essentially every negative offset (that
is, starting *before* the alloca does) would be thrown out, even if it
was overlapping. The subsequent code to throw out negative offsets which
were actually non-overlapping was essentially dead. The code to *handle*
overlapping negative offsets was actually dead!

I've just removed all of this, and taught SROA to discard any uses which
start prior to the alloca from the beginning. It has the lovely property
of simplifying the code. =] All the tests still pass, and in fact no new
tests are needed as this is already covered by our testsuite. Fixing the
code so that negative offsets work the way the comments indicate they
were supposed to work causes regressions. That's how I found this.

Anyways, this is all progress in the correct direction -- tightening up
SROA to be maximally aggressive. Some day, I really hope to turn
out-of-bounds accesses to an alloca into 'unreachable'.

llvm-svn: 169120

llvm-svn: 169119

[asan] in asan tests, check all return values of pthread_create/pthread_join. Also add the ASAN_AVOID_EXPENSIVE_TESTS macro to guard the test that creates too many threads

llvm-svn: 169118

llvm-svn: 169117

llvm-svn: 169116

This document is a long-time pet peeve :-) More fixes to come.

llvm-svn: 169115

llvm-svn: 169114

If user specifies aborting after a recoverable failed check is
appropriate, frontend should emit call to the _abort variant.

Test this behavior with newly added -fsanitize-recover flag.

llvm-svn: 169113

llvm-svn: 169112

llvm-svn: 169111

llvm-svn: 169110

; CHECK: [[VAR:[a-z]]]

The problem was that to find the end of the regex var definition, it was
simplistically looking for the next ]] and finding the incorrect one. A
better approach is to count nesting of brackets (taking escaping into
account). This way the brackets that are part of the regex can be discovered
and skipped properly, and the ]] ending is detected in the right place.

llvm-svn: 169109

llvm-svn: 169108

trivially achievable with an editor. I'll likely check in a silly python
script to help with this too.

llvm-svn: 169107

llvm-svn: 169106

and recursive copying is not required for the tutorial/ directory.

llvm-svn: 169105

files from tutorial/.svn

llvm-svn: 169104

matching a variable defined on the same line.

llvm-svn: 169103

Patch contributed by Wladimir J. van der Laan <laanwj@gmail.com>

llvm-svn: 169102