Change some ARM subtarget features to be single bit yes/no in order to sink them down to MC layer. Also fix tests.

llvm-svn: 134590

llvm-svn: 134589

e.g.

#define M(x) A x B
M(##) // should expand to 'A ## B', not 'AB'

llvm-svn: 134588

When a macro instantiation occurs, reserve a SLocEntry chunk with length the
full length of the macro definition source. Set the spelling location of this chunk
to point to the start of the macro definition and any tokens that are lexed directly
from the macro definition will get a location from this chunk with the appropriate offset.

For any tokens that come from argument expansion, '##' paste operator, etc. have their
instantiation location point at the appropriate place in the instantiated macro definition
(the argument identifier and the '##' token respectively).
This improves macro instantiation diagnostics:

Before:

t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
        ^~~~
t.c:5:11: note: instantiated from:
int y = M(/);
          ^

After:

t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
        ^~~~
t.c:3:20: note: instantiated from:
\#define M(op) (foo op 3);
                ~~~ ^  ~
t.c:5:11: note: instantiated from:
int y = M(/);
          ^

The memory savings for a candidate boost library that abuses the preprocessor are:

- 32% less SLocEntries (37M -> 25M)
- 30% reduction in PCH file size (900M -> 635M)
- 50% reduction in memory usage for the SLocEntry table (1.6G -> 800M)

llvm-svn: 134587

It would add up relative (decomposed) offsets like in getDecomposedSpellingLocSlowCase, but while
it makes sense to preserve the offset among lexed spelling locations, it doesn't make
sense to add anything to the offset of the instantiation location. The instantiation
location will be the same regardless of the relative offset in the tokens that were
instantiated.

This bug didn't actually affect anything because, currently, in practice we never create macro
locations with relative offset greater than 0.

llvm-svn: 134586

llvm-svn: 134585

llvm-svn: 134584

expressions.

llvm-svn: 134583

variables prior to running your binary. Zero filled sections now get
section data correctly filled with zeroes when Target::ReadMemory
reads from the object file section data.

Added new option groups and option values for file lists. I still need
to hook up all of the options to "target variable" to allow more complete
introspection by file and shlib.

Added the ability for ValueObjectVariable objects to be created with
only the target as the execution context. This allows them to be read
from the object files through Target::ReadMemory(...). 

Added a "virtual Module * GetModule()" function to the ValueObject
class. By default it will look to the parent variable object and
return its module. The module is needed when we have global variables
that have file addresses (virtual addresses that are specific to
module object files) and in turn allows global variables to be displayed
prior to running.

Removed all of the unused proxy object support that bit rotted in 
lldb_private::Value.

Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code
with the more efficient "FileSpec::Equal (lhs, rhs)".

Improved logging in GDB remote plug-in.

llvm-svn: 134579

llvm-svn: 134578

llvm-svn: 134577

So users of a CGI don't have to look up the value directly from the original
Record; just like the rest of the convenience values in the class.

llvm-svn: 134576

llvm-svn: 134575

some changes to the help system code for better display of long help text
-p and -r flags now also work for type format add

llvm-svn: 134574

llvm-svn: 134573

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