within the codegen EK_GPRel64BlockAddress. This was not 
supported for direct object output and resulted in an assertion.

This change adds support for EK_GPRel64BlockAddress for 
direct object.

One fallout from this is to turn on rela relocations 
for mips64 to match gas.

llvm-svn: 162334

SelectionDAG's 'init' has not been called when the SelectionDAGBuilder is
constructed (in SelectionDAGISel's constructor), so this was previously always
initialized with 0.

llvm-svn: 162333

'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found
or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.py test file.

llvm-svn: 162332

Reduce alignment of SmallVector<T> to the required amount, rather than forcing 16-byte alignment. This fixes misaligned SmallVector accesses via ExtractValueInst's SmallVector data member.

llvm-svn: 162331

llvm-svn: 162330

Patch by Weiming Zhao <weimingz@codeaurora.org>.

llvm-svn: 162329

Fix test failures in TestWatchpointIter.py due to http://llvm.org/viewvc/llvm-project?rev=162322&view=rev.

llvm-svn: 162328

between Bob, Jim, Eric and I, we've decided to take a slightly different
approach.

llvm-svn: 162327

llvm-svn: 162325

llvm-svn: 162324

Remove the process->DisableWatchpoint() and EnableWatchpoint() calls since the sentry object is already doing that.

llvm-svn: 162323

Watchpoint conditions were hitting watchpoint, smashing LLDB's stack.
Make sure watchpoint is properly disabled and subsequently enabled while performing watchpoint actions.

llvm-svn: 162322

Add a new static function, buildMSAsmPieces, that will break these strings down
into mnemonic and operands.  Upon a match failure, the idea is to use the
ErrorInfo from MatchInstructionImpl to inspect the mnemonic/operand and 
decide a course of action.  Unfortunately, there's no easy way to test this at
the moment.

llvm-svn: 162321

// rdar://12103400

llvm-svn: 162320

class extensions a little. clang now allows readonly property 
with no ownership rule (assign, unsafe_unretained, weak, retain, 
strong, or copy) with a readwrite property with an ownership rule.
// rdar://12103400 

llvm-svn: 162319

Under -analyzer-ipa=basic-inlining, only C functions, blocks, and C++ static
member functions are inlined -- essentially, the calls that behave like simple
C function calls. This is essentially the behavior in Xcode 4.4.

C++ support still has some rough edges, and we don't want users to be worried
about them if they download and run their own checker. (In particular, the
massive number of false positives for analyzing LLVM comes from inlining
defensively-written code in contexts where more aggressive assumptions are
implicitly made. This problem is not unique to C++, but it is exacerbated by
the higher proportion of code that lives in header files in C++.)

The eventual goal is to be comfortable enough with C++ support (and simple
Objective-C support) to advance to -analyzer-ipa=inlining as the default
behavior. See the IPA design notes for more details.

llvm-svn: 162318

The actual change here is a little more complicated than the summary above.
What we want to do is have our generic inlining tests run under whatever
mode is the default. However, there are some tests that depend on the
presence of C++ inlining, which still has some rough edges. These tests have
been explicitly marked as -analyzer-ipa=inlining in preparation for a new
mode that limits inlining to C functions and blocks. This will be the
default until the false positives for C++ have been brought down to
manageable levels.

llvm-svn: 162317

llvm-svn: 162316

Skip paragraphs that contain only whitespace.

llvm-svn: 162315

strict weak ordering, and don't pass possibly-null pointers to dyn_cast.

llvm-svn: 162314

This reduces duplication across the Basic and Range constraint managers, and
keeps their internals free of dealing with the semantics of C++. It's still
a little unfortunate that the constraint manager is dealing with this at all,
but this is pretty much the only place to put it so that it will apply to all
symbolic values, even when embedded in larger expressions.

llvm-svn: 162313

int64_t, Symbol64TableEntry is actually only stored with 4-byte alignment
within the file.

The usage of #pragma pack here is copied from the corresponding code in
Support/Endian.h, so shouldn't introduce any new portability problems.

llvm-svn: 162312

no cost to using memcpy here: the fixed code is optimized by LLVM to perfect
machine code.

llvm-svn: 162311

llvm-svn: 162310

llvm-svn: 162309

llvm-svn: 162308

llvm-svn: 162307

llvm-svn: 162306

According to http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html
it's suggested that compile_commands.json in the root of the LLVM source tree
should be a symlink to the json file produced by your build system of choice.

So here's a patch so it doesn't turn up in git status, etc.

llvm-svn: 162305

Thanks to Duncan Sands for catching this random file in code review.

llvm-svn: 162304

for structure valued method messaging. // rdar://12142241

llvm-svn: 162303

(from a todo mentioned in r159469 & originally suggested by Chandler Carruth)

llvm-svn: 162302

Even looking at the revision history I couldn't quite piece together why this
cast was ever written in the first place, but I assume it was because of some
change in the inheritance, perhaps this function was reimplemented in a
derived type & this caller was meant to get the base version (& it wasn't
virtual)?

llvm-svn: 162301

llvm-svn: 162300

llvm-svn: 162299

on a patch by Andy/PaX. I added the support for dot and dollar.

llvm-svn: 162298

llvm-svn: 162297

this is the index of the operand that failed to match.

llvm-svn: 162296

this is the index of the operand that failed to match.

Note: This may cause a buildbot failure due to an API mismatch in clang.  Should
recover with my next commit to clang.

llvm-svn: 162295

llvm-svn: 162294