for this class. These tests exercise most of the basic properties, but
the API for TinyPtrVector is very strange currently. My plan is to start
fleshing out the API to match that of SmallVector, but I wanted a test
for what is there first.

Sadly, it doesn't look reasonable to just re-use the SmallVector tests,
as this container can only ever store pointers, and much of the
SmallVector testing is to get construction and destruction right.

Just to get this basic test working, I had to add value_type to the
interface.

While here I found a subtle bug in the combination of 'erase', 'begin',
and 'end'. Both 'begin' and 'end' wanted to use a null pointer to
indicate the "end" iterator of an empty vector, regardless of whether
there is actually a vector allocated or the pointer union is null.
Everything else was fine with this except for erase. If you erase the
last element of a vector after it has held more than one element, we
return the end iterator of the underlying SmallVector which need not be
a null pointer. Instead, simply use the pointer, and poniter + size()
begin/end definitions in the tiny case, and delegate to the inner vector
whenever it is present.

llvm-svn: 161024

We are extending live ranges, so kill flags are not accurate. They
aren't needed until they are recomputed after RA anyway.

<rdar://problem/11950722>

llvm-svn: 161023

attribute. It is a variation of the x86_64 ABI:

* A struct returned indirectly uses the first register argument to pass the
  pointer.
* Floats, Doubles and structs containing only one of them are not passed in
  registers.
* Other structs are split into registers if they fit on the remaining ones.
  Otherwise they are passed in memory.
* When a struct doesn't fit it still consumes the registers.

llvm-svn: 161022

llvm-svn: 161021

type and then propagated to the function. This was failing for destructors,
constructors and constructors templates since they don't have a return type.

Fix that by directly calling processTypeAttrs on the dummy type we use as the
return type in these cases.

llvm-svn: 161020

llvm-svn: 161019

We branch to the successor with higher edge weight first.
Convert from
     je    LBB4_8  --> to outer loop
     jmp   LBB4_14 --> to inner loop
to
     jne   LBB4_14
     jmp   LBB4_8

PR12750
rdar: 11393714

llvm-svn: 161018

This removes explicit checks for 'this' and 'self' from
Store::enterStackFrame. It also removes getCXXThisRegion() as a virtual
method on all CallEvents; it's now only implemented in the parts of the
hierarchy where it is relevant. Finally, it removes the option to ask
for the ParmVarDecls attached to the definition of an inlined function,
saving a recomputation of the result of getRuntimeDefinition().

No visible functionality change!

llvm-svn: 161017

This is just a clarification on Fariborz's original patch, per e-mail
discussion. No functionality change.

llvm-svn: 161016

lambda-introducer in Objective-C++11, fall back to treating the tokens
as an Objective-C message send to provide those (more likely)
completions. Fixes <rdar://problem/11980263>.

llvm-svn: 161015

this-adjustment thunk in ARC++.

llvm-svn: 161014

Fixed an issue where warning logs were causing a crash.

llvm-svn: 161013

Use self-init.m for testing. (It used to have a bunch of failing tests
with dynamic inlining turned on.)

llvm-svn: 161012

The inlinable portion of the test relies on attributes/instead of the
function implementation.

llvm-svn: 161011

llvm-svn: 161010

llvm-svn: 161009

sure to update the exception specification on the declaration as well as the
definition. If we're building in -fno-exceptions mode, nothing else will
trigger it to be updated.

llvm-svn: 161008

llvm-svn: 161007

CallInst for intrinsics. This allows users of the InstVisitor that would
like to special case certain very common intrinsics to do so naturally
in keeping with the type hierarchy's utility classes.

llvm-svn: 161006

Previously, we were only checking the origin expressions of inlined calls.
Checkers using the generic postCall and older postObjCMessage callbacks were
ignored. Now that we have CallEventManager, it is much easier to create
a CallEvent generically when exiting an inlined function, which we can then
use for post-call checks.

No test case because we don't (yet) have any checkers that depend on this
behavior (which is why it hadn't been fixed before now).

llvm-svn: 161005

llvm-svn: 161004

This lets traces include the final iteration of a nested loop above the
center block, and the first iteration of a nested loop below the center
block.

We still don't allow traces to contain backedges, and traces are
truncated where they would leave a loop, as seen from the center block.

llvm-svn: 161003

Empty macro arguments at the end of the list should be as-if not specified at
all, but those in the middle of the list need to be kept so as not to screw
up the positional numbering. E.g.:
.macro foo
foo_-bash___:
  nop
.endm

foo 1, 2, 3, 4
foo 1, , 3, 4

Should create two labels, "foo_1_2_3_4" and "foo_1__3_4".

rdar://11948769

llvm-svn: 161002

test more than a single instantiation of SmallVector.

Add testing for 0, 1, 2, and 4 element sized "small" buffers. These
appear to be essentially untested in the unit tests until now.

Fix several tests to be robust in the face of a '0' small buffer. As
a consequence of this size buffer, the growth patterns are actually
observable in the test -- yes this means that many tests never caused
a grow to occur before. For some tests I've merely added a reserve call
to normalize behavior. For others, the growth is actually interesting,
and so I captured the fact that growth would occur and adjusted the
assertions to not assume how rapidly growth occured.

Also update the specialization for a '0' small buffer length to have all
the same interface points as the normal small vector.

llvm-svn: 161001

Don't set the thread when adopting selected execution context entries, and use the "lldb_private::StateIsStoppedState(StateType, bool)" function to tell if the state is stopped.

llvm-svn: 161000

Extend the ',' versus ';' diagnostic for -Wvexing-parse to cover the with-arguments case as well as the no-arguments case.

llvm-svn: 160999

accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.

Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.

llvm-svn: 160998

llvm-svn: 160997

llvm-svn: 160996

When computing a trace, all the candidates for pred/succ must have been
visited. Filter out back-edges first, though. The PO traversal ignores
them.

Thanks to Andy for spotting this in review.

llvm-svn: 160995

By overriding Pass::verifyAnalysis(), the pass contents will be verified
by the pass manager.

llvm-svn: 160994

type of generated call to super dealloc is 'void'
and asserts if user's dealloc is not of 'void type.
This rule must be enforced in clang front-end (with a 
fixit) if this is not the case, instead of asserting in CodeGen.
// rdar://11987838

llvm-svn: 160993

- Retrieves the type of the object/receiver from the state.
- Binds self during stack setup.
- Only explores the path on which the method is inlined (no
bifurcation to explore the path on which the method is not inlined).

llvm-svn: 160991

llvm-svn: 160990

llvm-svn: 160989

dispatched methods.

Disabled by default for now.

llvm-svn: 160988

Consider address spaces for hashing and CSEing DAG nodes.  Otherwise two loads from different x86 segments but the same address would get CSEd

llvm-svn: 160987

This ensures that it is valid to reference-count any CallEvents, and we
won't accidentally try to reclaim a CallEvent that lives on the stack.
It also hides an ugly switch statement for handling CallExprs!

There should be no functionality change here.

llvm-svn: 160986

No functionality change.

llvm-svn: 160985

While '%n' can be used for evil in an attacker-controlled format string, there
isn't any acute danger in using it in a literal format string with an argument
of the appropriate type.

llvm-svn: 160984