Apparently the output of this test is not deterministic.  Needs investigation.

llvm-svn: 163377

[Sanitizer] add --demangle option to llvm-symbolizer (for now just assume that __cxa_demangle option is available)

llvm-svn: 163376

While the check itself should count 0-based for the parameter index,
the diagnostic should be 1-based (first, second, third, not start at 0).

Fixes <rdar://problem/12249569>.

llvm-svn: 163375

(as this previously was the case before this was refactored).  We also shouldn't
need to specially handle BinaryOperators since the eagerly-assume heuristic tags
such nodes.

llvm-svn: 163374

of the analyzer, as the RetainReleaseChecker has many fine-grain
path diagnostic events that were not being checked.  This uncovered
an inconsistency between the path diagnostics between Objective-C
and Objective-C++ code in ConditionBRVisitor that was fixed in a recent
patch.

llvm-svn: 163373

implicit pointer-to-boolean conversions in condition expressions.  This would
result in inconsistent diagnostic emission between C and C++.

A consequence of this is now ConditionBRVisitor and TrackConstraintBRVisitor may
emit redundant diagnostics, for example:

  "Assuming pointer value is null" (TrackConstraintBRVisitor)
  "Assuming 'p' is null" (ConditionBRVisitor)

We need to reconcile the two, and perhaps prefer one over the other in some
cases.

llvm-svn: 163372

Add -exact-match option to FileCheck to allow clients to do exact matches without using regular expressions.

llvm-svn: 163371

- this should fix PR13780

llvm-svn: 163370

unexpanded parameter pack is a pack expansion. Thus, as with a non-type template
parameter which is a pack expansion, it needs to be expanded early into a fixed
list of template parameters.

Since the expanded list of template parameters is not itself a parameter pack,
it is permitted to appear before the end of the template parameter list, so also
remove that restriction (for both template template parameter pack expansions and
non-type template parameter pack expansions).

llvm-svn: 163369

The assembler can alias one instruction into another based
on the operands. For example the jump instruction "J" takes
and immediate operand, but if the operand is a register the
assembler will change it into a jump register "JR" instruction.

These changes are in the instruction td file.

Test cases included

Contributer: Vladimir Medic
llvm-svn: 163368

With some particularly evil casts, we can get an object whose dynamic type
is not actually a subclass of its static type. In this case, we won't even
find the statically-resolved method as a devirtualization candidate.

Rather than assert that this situation cannot occur, we now simply check
that the dynamic type is not an ancestor or descendent of the static type,
and leave it at that.

This error actually occurred analyzing LLVM: CallEventManager uses a
BumpPtrAllocator to allocate a concrete subclass of CallEvent
(FunctionCall), but then casts it to the actual subclass requested
(such as ObjCMethodCall) to perform the constructor.

Yet another crash in PR13763.

llvm-svn: 163367

llvm-svn: 163366

llvm-svn: 163365

Actually these are just stubs for parsing the directives.
Semantic support will come later.

Test cases included

Contributer: Vladimir Medic
llvm-svn: 163364

Test cases included

Contributer: Vladimir Medic
llvm-svn: 163363

return a CF object at all.

Fixes <rdar://problem/9566345>

llvm-svn: 163362

A bizarre series of coincidences led us to generate a previously-seen
node in the middle of processing an Objective-C message, where we assume
the receiver is non-nil. We were assuming that such an assumption would
never "cache out" like this, and blithely went on using a null ExplodedNode
as the predecessor for the next step in evaluation.

Although the test case committed here is complicated, this could in theory
happen in other ways as well, so the correct fix is just to test if the
non-nil assumption results in an ExplodedNode we've seen before.

<rdar://problem/12243648>

llvm-svn: 163361

- This patch is inspired by the failure of the following code snippet
  which is used to convert enumerable values into encoding bits to
  improve the readability of td files.

  class S<int s> {
    bits<2> V = !if(!eq(s, 8),  {0, 0},
                !if(!eq(s, 16), {0, 1},
                !if(!eq(s, 32), {1, 0},
                !if(!eq(s, 64), {1, 1}, {?, ?}))));
  }

  Later, PR8330 is found to report not exactly the same bug relevant
  issue to bit/bits values.

- Instead of resolving bit/bits values separately through
  resolveBitReference(), this patch adds getBit() for all Inits and
  resolves bit value by resolving plus getting the specified bit. This
  unifies the resolving of bit with other values and removes redundant
  logic for resolving bit only. In addition,
  BitsInit::resolveReferences() is optimized to take advantage of this
  origanization by resolving VarBitInit's variable reference first and
  then getting bits from it.

- The type interference in '!if' operator is revised to support possible
  combinations of int and bits/bit in MHS and RHS.

- As there may be illegal assignments from integer value to bit, says
  assign 2 to a bit, but we only check this during instantiation in some
  cases, e.g.

  bit V = !if(!eq(x, 17), 0, 2);

  Verbose diagnostic message is generated when invalid value is
  resolveed to help locating the error.

- PR8330 is fixed as well.

llvm-svn: 163360

llvm-svn: 163359

llvm-svn: 163358

llvm-svn: 163357

via function/method with [CF,NS]_RETURNS_NOT_RETAINED.

Fixes <rdar://problem/11379000>.

llvm-svn: 163355

llvm-svn: 163354

are used in EH code.  Right now the CFG doesn't support exceptions well,
so we need this hack to avoid bogus dead store warnings.

Fixes <rdar://problem/12147586>

llvm-svn: 163353

llvm-svn: 163352

llvm-svn: 163351

llvm-svn: 163350

llvm-svn: 163349

CXXDestructorCall now has a flag for when it is a base destructor call.
Other kinds of destructor calls (locals, fields, temporaries, and 'delete')
all behave as "whole-object" destructors and do not behave differently
from one another (specifically, in these cases we /should/ try to
devirtualize a call to a virtual destructor).

This was causing crashes in both our internal buildbot, the crash still
being tracked in PR13765, and some of the crashes being tracked in PR13763,
due to a assertion failure. (The behavior under -Asserts happened to be
correct anyway.)

Adding this knowledge also allows our DynamicTypePropagation checker to do
a bit less work; the special rules about virtual method calls during a
destructor only require extra handling during base destructors.

llvm-svn: 163348

This includes sb,sc,sh,sw,lb,lw,lbu,lh,lhu,ll,lw

Test case included

Contributer: Vladimir Medic
llvm-svn: 163346

handle.  Otherwise, the AsmParser will explode if we try to generate an
object files.

llvm-svn: 163345

No functional change.

llvm-svn: 163344

Thanks, Andy.

llvm-svn: 163343

and output expressions much like that in GNU-style inline assembly. Output
expressions are first.  Do this for MS-style inline asms.

llvm-svn: 163342

llvm-svn: 163341

llvm-svn: 163340

No functional change.

llvm-svn: 163339

// rdar://12233989

llvm-svn: 163338

Don't try to check override control for invalid member functions. Fixes a crash in a corner case. Patch by Olivier Goffart!

llvm-svn: 163337

The RegisterCoalescer understands overlapping live ranges where one
register is defined as a copy of the other. With this change, register
allocators using LiveRegMatrix can do the same, at least for copies
between physical and virtual registers.

When a physreg is defined by a copy from a virtreg, allow those live
ranges to overlap:

  %CL<def> = COPY %vreg11:sub_8bit; GR32_ABCD:%vreg11
  %vreg13<def,tied1> = SAR32rCL %vreg13<tied0>, %CL<imp-use,kill>

We can assign %vreg11 to %ECX, overlapping the live range of %CL.

llvm-svn: 163336