llvm-svn: 180713

Patch by Alex Denisov.

llvm-svn: 180712

For MachO we need information that is not represented in ObjRelocationInfo.
Instead of copying the bits we think are needed from a relocation_iterator,
just pass the relocation_iterator down to the format specific functions.

No functionality change yet as we still drop the information once
processRelocationRef returns.

llvm-svn: 180711

Add a CapturedStmt.h similar to Lambda.h to reduce the typing required to get
to the CapturedRegionKind enum. This also allows codegen to access this enum
without including Sema/ScopeInfo.h.

Also removes some duplicated code for capturing 'this' between CapturedStmt and
Lambda.

Differential Revision: http://llvm-reviews.chandlerc.com/D712

llvm-svn: 180710

llvm-svn: 180709

late-parsed templates. Patch by Faisal Vali!

llvm-svn: 180708

performed within the context of that class template. Patch by Ismail Pazarbasi!

llvm-svn: 180707

print the disassembly context around $pc -- just print the filename and line number, even if we 
can't show the source code.  Previously if the source file was not available, lldb would print
the source filename & line number and assembly.  
<rdar://problem/13072951> 

llvm-svn: 180706

will run xcode-select --print-path to find the currently selected 
Xcode developer directory.  Mostly useful for when lldb is not being run out
of the /Applications/Xcode.app bundle so it can't locate the iOS or
kernel SDKs.

llvm-svn: 180705

with directories, without increasing the size of the FileSpec object.
GetPath() returns a std::string of the full pathname of the file.
IsDirectory(), IsPipe(), IsRegularFile(), IsSocket(), and IsSymbolicLink()
can be used instead of getting the FileType() and comparing it to an enum.

Update PlatformDarwinKernel to use these new methods.

llvm-svn: 180704

llvm-svn: 180703

within a dependent context. Patch by Will Wilson (+clang-format)!

llvm-svn: 180702

a dependent-scope id expression when a templated member function of a
non-templated class references an unknown identifier, since instantiation won't
rebuild it (and we can tell at parse time that it'll never work). Based on a
patch by Faisal Vali!

llvm-svn: 180701

llvm-svn: 180700

[objc-arc] Apply the RV optimization to retains next to calls in ObjCARCContract instead of ObjCARCOpts.

Turning retains into retainRV calls disrupts the data flow analysis in
ObjCARCOpts. Thus we move it as late as we can by moving it into
ObjCARCContract.

We leave in the conversion from retainRV -> retain in ObjCARCOpt since
it enables the dataflow analysis.

rdar://10813093

llvm-svn: 180698

llvm-svn: 180697

llvm-svn: 180696

llvm-svn: 180694

[objc-arc-annotations] Moved the disabling of call movement to ConnectTDBUTraversals so that I can prevent Changed = true from being set. This prevents an infinite loop.

llvm-svn: 180693

[lld][ELF] (no testable functionality change) resize the number of entries in the string table for static linking

llvm-svn: 180692

[lld][ELF] (no testable functionality change) resize the number of entries in the string table for static linking

llvm-svn: 180691

llvm-svn: 180690

llvm-svn: 180688

delete blank.

llvm-svn: 180687

llvm-svn: 180686

llvm-svn: 180685

llvm-svn: 180684

llvm-svn: 180683

Patch by Robert Wilhelm.

llvm-svn: 180682

llvm-svn: 180680

llvm-svn: 180679

llvm-svn: 180678

Handle tied sub-operands in AsmMatcherEmitter

The problem this patch addresses is the handling of register tie
constraints in AsmMatcherEmitter, where one operand is tied to a
sub-operand of another operand.  The typical scenario for this to
happen is the tie between the "write-back" register of a pre-inc
instruction, and the base register sub-operand of the memory address
operand of that instruction.

The current AsmMatcherEmitter code attempts to handle tied
operands by emitting the operand as usual first, and emitting
a CVT_Tied node when handling the second (tied) operand.  However,
this really only works correctly if the tied operand does not
have sub-operands (and isn't a sub-operand itself).  Under those
circumstances, a wrong MC operand list is generated.

In discussions with Jim Grosbach, it turned out that the MC operand
list really ought not to contain tied operands in the first place;
instead, it ought to consist of exactly those operands that are
named in the AsmString.  However, getting there requires significant
rework of (some) targets.

This patch fixes the immediate problem, and at the same time makes
one (small) step in the direction of the long-term solution, by
implementing two changes:

1. Restricts the AsmMatcherEmitter handling of tied operands to
   apply solely to simple operands (not complex operands or
   sub-operand of such).

This means that at least we don't get silently corrupt MC operand
lists as output.  However, if we do have tied sub-operands, they
would now no longer be handled at all, except for:

2. If we have an operand that does not occur in the AsmString,
   and also isn't handled as tied operand, simply emit a dummy
   MC operand (constant 0).

This works as long as target code never attempts to access
MC operands that do no not occur in the AsmString (and are
not tied simple operands), which happens to be the case for
all targets where this situation can occur (ARM and PowerPC).

[ Note that this change means that many of the ARM custom
  converters are now superfluous, since the implement the
  same "hack" now performed already by common code. ]

Longer term, we ought to fix targets to never access *any*
MC operand that does not occur in the AsmString (including
tied simple operands), and then finally completely remove
all such operands from the MC operand list.

Patch approved by Jim Grosbach.

llvm-svn: 180677

When Reassociator optimize "(x | C1)" ^ "(X & C2)", it may swap the two
subexpressions, however, it forgot to swap cached constants (of C1 and C2)
accordingly.

rdar://13739160

llvm-svn: 180676

Patch by Dimitry Andric.

llvm-svn: 180675

Patch by Dimitry Andric

llvm-svn: 180674

llvm-svn: 180673

llvm-svn: 180672

The CodeGen aspects of this test are already covered by cfi-frame.ll;
making it an assembly file reduces the risk of incidental changes
affecting the test.

llvm-svn: 180671

llvm-svn: 180670