llvm-svn: 134572

llvm-svn: 134571

Do not violate the opencl casting rules. This test case still illustrates the problem. In the future, we should throw an error when doing invalid casting.

llvm-svn: 134570

Factor ARM triple parsing out of ARMSubtarget. Another step towards making ARM subtarget info available to MC.

llvm-svn: 134569

llvm-svn: 134568

llvm-svn: 134567

llvm-svn: 134566

When tail-merging multiple blocks, make sure to correctly update the live-in list on the merged block to correctly account for the live-outs of all the predecessors.  They might not be the same in all cases (the testcase I have involves a PHI node where one of the operands is an IMPLICIT_DEF).

Unfortunately, the testcase I have is large and confidential, so I don't have a test to commit at the moment; I'll see if I can come up with something smaller where this issue reproduces.

<rdar://problem/9716278>

llvm-svn: 134565

llvm-svn: 134563

RecursiveASTVisitor.

This deficiency was discovered while working with the AST matcher
framework and likely impacts other users of RecursiveASTMatcher who
previously weren't seeing these Decls in their visitation.

Patch reviewed by Chandler Carruth.

llvm-svn: 134562

llvm-svn: 134561

llvm-svn: 134560

llvm-svn: 134559

on class declarations. Documentation for // rdar://9693477

llvm-svn: 134558

llvm-svn: 134557

attribute on property. Document for // rdar://9636091.

llvm-svn: 134556

llvm-svn: 134555

  vec.insert(vec.begin(), vec[3]);
The issue was that vec[3] returns a reference into the vector, which is invalidated when insert() memmove's the elements down to make space.  The method needs to specifically detect and handle this case to correctly match std::vector's semantics.

Thanks to Howard Hinnant for clarifying the correct behavior, and explaining how std::vector solves this problem.

llvm-svn: 134554

the presence of 'const'.  Ifndef the non-const one out.

llvm-svn: 134553

rather than a computed std::distance(). At some point I had convinced
myself that these two were different; but as far as I can tell on
re-exampination they aren't, and the number of block IDs is actually
just a count of the blocks in the CFG.

While this removes the primary motivation for guarding all of this with
CollectStats, I have a patch coming up that will almost certainly make
it important again.

llvm-svn: 134552

llvm-svn: 134551

llvm-svn: 134550

llvm-svn: 134549

throw-expressions, such that we don't consider the NRVO when the
non-volatile automatic object comes from outside the innermost try
scope (C++0x [class.copymove]p13). In C++98/03, our ASTs were
incorrect but it didn't matter because IR generation doesn't actually
apply the NRVO here. In C++0x, however, we were moving from an object
when in fact we should have copied from it. Fixes PR10142 /
<rdar://problem/9714312>.

llvm-svn: 134548

llvm-svn: 134547

llvm-svn: 134546

llvm-svn: 134545

llvm-svn: 134544

Add post-processing step to transform the docstring from 'char', i.e., 'char *', to 'str', i.e., Python string.

llvm-svn: 134543

llvm-svn: 134541

This allows us to remove the (bogus and unneeded) encoding information from
the pseudo-instruction class definitions. All of the pseudos that haven't
been converted yet and still need encoding information instance from the normal
instruction classes and explicitly set isCodeGenOnly, and so are distinct
from this change.

llvm-svn: 134540

For now this is distinct from isCodeGenOnly, as code-gen-only
instructions can (and often do) still have encoding information
associated with them. Once we've migrated all of them over to true
pseudo-instructions that are lowered to real instructions prior to
the printer/emitter, we can remove isCodeGenOnly and just use isPseudo.

llvm-svn: 134539

llvm-svn: 134538

careful about referencing values.

llvm-svn: 134537

llvm-svn: 134536

llvm-svn: 134534

Pseudo-instructions don't have encoding information, as they're lowered
to real instructions by the time we're doing binary encoding.

llvm-svn: 134533

llvm-svn: 134532

not test for this.

llvm-svn: 134531

llvm-svn: 134530