llvm-svn: 160464

llvm-svn: 160463

llvm-svn: 160462

As pointed out by Anna, we only differentiate between explicit message sends

This also adds support for ObjCSubscriptExprs, which are basically the same
as properties in many ways. We were already checking these, but not emitting
nice messages for them.

This depends on the llvm::PointerIntPair change in r160456.

llvm-svn: 160461

Per Anna's comment that "add..." sounds like a method that modifies
the receiver, rather than its argument.

No functionality change.

llvm-svn: 160460

We will need to be able to easily reconstruct a CallEvent from an ExplodedNode
for diagnostic purposes, and that's exactly what factory functions are for.
CallEvent objects are small enough (four pointers and a SourceLocation) that
returning them through the stack is fairly cheap. Clients who just need to use
existing CallEvents can continue to do so using const references.

This uses the same sort of "kind-field-dispatch" as SVal, though most of the
nastiness is contained in the DISPATCH and DISPATCH_ARG macros at the end of
the file. (We can't use a template for this because member-pointers to base
class methods don't call derived-class methods even when casting to the
derived class. We can't use variadic macros because they're a C99 feature.)

llvm-svn: 160459

ObjC properties are handled through their semantic form of ObjCMessageExprs
and their wrapper PseudoObjectExprs, and have been for quite a while. The
syntactic ObjCPropertyRefExprs do not appear in the CFG and are not visited
by ExprEngine.

No functionality change.

llvm-svn: 160458

llvm-svn: 160457

For a measure of safety, this conversion is only permitted if the
stored pointer type can also be created from a const void *.

llvm-svn: 160456

llvm-svn: 160455

Updated OptimizeCompare in peephole to remove redundant cmp against zero.
We only remove Compare if CF and OF are not used.

rdar://11855129

llvm-svn: 160454

llvm-svn: 160453

llvm-svn: 160452

when run on an Intel Atom processor. The failures have arisen due
to changes elsewhere in the trunk over the past 8 weeks or so.

These failures were not detected by the Atom buildbot because the
CPU on the Atom buildbot was not being detected as an Atom CPU.
The fix for this problem is in Host.cpp and X86Subtarget.cpp, but
shall remain commented out until the current set of Atom test failures
are fixed.

Patch by Andy Zhang and Tyler Nowicki!

llvm-svn: 160451

Improved the error message when we can find a function in the current program by printing the demangled name.

Also added the ability to create lldb_private::Mangled instances with a ConstString when we already have a ConstString for a mangled or demangled name. Also added the ability to call SetValue with a ConstString and also without a boolean to indicate if the string is mangled where we will now auto-detect if the string is mangled.

llvm-svn: 160450

single element.  Also modified our struct test
case to test this.

llvm-svn: 160449

Cleaned up incorrect STL std::map comparison code and use the operator == on std::map objects instead of manually implementing the comparisons. Also modified the UnwindPlan::AppendRow() function to take a "const RowSP &" object so we don't have to copy shared pointers when calling this function.

llvm-svn: 160448

llvm-svn: 160446

llvm-svn: 160445

This enables the faster SmallVector in clang and also allows clang's unused
variable warnings to be more effective. Fix the two instances that popped up.

The RetainCountChecker change actually changes functionality, it would be nice
if someone from the StaticAnalyzer folks could look at it.

llvm-svn: 160444

LiveIntervals due to the two-addr pass generating bogus MI code.

The crux of the issue was a loop nesting problem. The intent of the code
which attempts to transform instructions before converting them to
two-addr form is to defer and reprocess any transformed instructions as
the second processing is likely to have more opportunities to coalesce
copies, etc. Unfortunately, there was one section of processing that was
not deferred -- the INSERT_SUBREG rewriting. Due to quirks of how this
rewriting proceeded, not only did it occur early, it removed the bits of
information needed for the deferred processing to correctly generate the
necessary two address form (specifically inserting a copy), but didn't
trigger any immediate assertions and produced what appeared to be
already valid two-address from code. Thus, the assertion only fired much
later in the pipeline.

The fix is to hoist the transformation logic up layer to where it can
more firmly defer all further processing, and to teach the normal
processing to handle an edge case previously handled as part of the
transformation logic. This edge case (already matched tied register
operands) needs to *not* defer any steps.

As has been brought up repeatedly in the process: wow does this code
need refactoring. I *may* squeeze in some time to at least bring sanity
to this loop... but wow... =]

Thanks to Jakob for helpful hints on the way here, and the review.

llvm-svn: 160443

<rdar://problem/11893881>

llvm-svn: 160442

Based on Evan's suggestion without a commitable test.

llvm-svn: 160441

llvm-svn: 160440

llvm-svn: 160439

llvm-svn: 160438

despite __attribute__(__used__).  As explained by Argyrios,
> .a archive files do some stripping of their own and they remove .o files that
> contain functions that are not referenced by any other .o file.

The fix is to use these functions from another .o file.

Thanks, Argyrios!

llvm-svn: 160437

[tsan] minor enhancements in the new tsan allocator and a test malloc replacement library that can be linked to any program to replace malloc (tested on spec2006)

llvm-svn: 160436

llvm-svn: 160435

- section types
- dynamic table entries tags
- state flags for DT_FLAGS_1 entry

The patch reviewed by Rafael Espindola.

llvm-svn: 160433

llvm-svn: 160432

llvm-svn: 160431

load source operand is used by multiple nodes. The v2i64 broadcast was emulated
by shuffling the two lower i32 elements to the upper two.
We had a bug in the immediate used for the broadcast.
Replacing 0 to 0x44.
0x44 means [01|00|01|00] which corresponds to the correct lane.

Patch by Michael Kuperstein.

llvm-svn: 160430

Print the high order register of a double word register operand.

In 32 bit mode, a 64 bit double word integer will be represented
by 2 32 bit registers. This modifier causes the high order register
to be used in the asm expression. It is useful if you are using 
doubles in assembler and continue to control register to variable
relationships.

This patch also fixes a related bug in a previous patch:

    case 'D': // Second part of a double word register operand
    case 'L': // Low order register of a double word register operand
    case 'M': // High order register of a double word register operand

I got 'D' and 'M' confused. The second part of a double word operand
will only match 'M' for one of the endianesses. I had 'L' and 'D'
be the opposite twins when 'L' and 'M' are.

llvm-svn: 160429

llvm-svn: 160428

(in uses of dynamic_cast<>).

Fixes <rdar://problem/11817693>.

llvm-svn: 160427

Expression trees may be DAGs. Make sure traversal has linear complexity.

llvm-svn: 160426

llvm-svn: 160425

Teach CFG construction about destructors resulting from references to array types.  Fixes crash in <rdar://problem/11671507>.

llvm-svn: 160424

llvm-svn: 160423