The result of clang_getCursorSpelling() needs to be clang_getCursorSpelling()ed.

llvm-svn: 207073

own CRTP base class for more general purpose use. Add some clarifying
comments for the exact way in which the adaptor uses it. Hopefully this
will help us write increasingly full featured iterators. This is
becoming important as they start to be used heavily inside of ranges.

llvm-svn: 207072

Tool::run() doesn't take ownership of the passed action.

llvm-svn: 207071

http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/22506

llvm-svn: 207070

Boost's iterator_adaptor, and a specific adaptor which iterates over
pointees when wrapped around an iterator over pointers.

This is the result of a long discussion on IRC with Duncan Smith, Dave
Blaikie, Richard Smith, and myself. Essentially, I could use some subset
of the iterator facade facilities often used from Boost, and everyone
seemed interested in having the functionality in a reasonably generic
form. I've tried to strike a balance between the pragmatism and the
established Boost design. The primary differences are:

1) Delegating to the standard iterator interface names rather than
   special names that then make up a second iterator-like API.
2) Using the name 'pointee_iterator' which seems more clear than
   'indirect_iterator'. The whole business of calling the '*p' operation
   'pointer indirection' in the standard is ... quite confusing. And
   'dereference' is no better of a term for moving from a pointer to
   a reference.

Hoping Duncan, and others continue to provide comments on this until
we've got a nice, minimal abstraction.

llvm-svn: 207069

llvm-svn: 207068

llvm-svn: 207067

llvm-svn: 207066

Also update a comment to match a code change that was done in r110978.

llvm-svn: 207065

llvm-svn: 207064

together. This is extremely hairy, because in general we need to have loaded
both the template and the pattern before we can determine whether either should
be merged, so we temporarily violate the rule that all merging happens before
reading a decl ends, but *only* in the case where a template's pattern is being
loaded while loading the template itself.

In order to accomodate this for class templates, delay loading the injected
class name type for the pattern of the template until after we've loaded the
template itself, if we happen to load the template first.

llvm-svn: 207063

llvm-svn: 207062

llvm-svn: 207061

llvm-svn: 207060

llvm-svn: 207059

This excludes avx512 as I don't have hardware to verify. It excludes _dq
variants because they are represented in the IR as <{2,4} x i64> when it's
actually a byte shift of the entire i{128,265}.

This also excludes _dq_bs as they aren't at all supported by the backend.
There are also no corresponding instructions in the ISA. I have no idea why
they exist...

llvm-svn: 207058

llvm-svn: 207057

Should suppress several LSan reports.

llvm-svn: 207056

Summary:
Since the upper 64 bits of the destination register are undefined when
performing this operation, we can substitute it and let the optimizer
figure out that only a copy is needed.

Also added range merging, if an instruction copies a range that can be
merged with a previous copied range.

Added test cases for both optimizations.

Reviewers: grosbach, nadav

CC: llvm-commits

Differential Revision: http://reviews.llvm.org/D3357

llvm-svn: 207055

llvm-svn: 207054

values rather than having pointers in weird places.

llvm-svn: 207053

llvm-svn: 207052

Fix for r207049 which would've emitted no accelerated names at all...

llvm-svn: 207051

llvm-svn: 207050

(similar changes coming for the other accelerator tables)

llvm-svn: 207049

iterator, returning a Node by reference on dereference.

llvm-svn: 207048

return references to better model this property.

No functionality changed.

llvm-svn: 207047

Allow summary formatters to take ValueObjects into account when deciding whether values/children should be printed and if child names should be shown
This decision has always been statically-bound to the individual formatter. With this patch, the idea is that this decision could potentially be dynamic depending on the ValueObject itself

llvm-svn: 207046

than functions. So far, this access pattern is *much* more common. It
seems likely that any user of this interface is going to have nodes at
the point that they are querying the SCCs.

No functionality changed.

llvm-svn: 207045

llvm-svn: 207044

This makes array_pod_sort portably safe to use with pointers.

llvm-svn: 207043

values rather than an expensive dense map query to test whether children
have already been popped into an SCC. This matches the incremental SCC
building code. I've also included the assert that I put there but
updated both of their text.

No functionality changed here.

I still don't have any great ideas for sharing the code between the two
implementations, but I may try a brute-force approach to factoring it at
some point.

llvm-svn: 207042

llvm-svn: 207041

llvm-svn: 207040

llvm-svn: 207039

This is dependent on changes that are not fully ready to be merged yet (WoA
object file emission).  The test can be re-enabled for that target later.

llvm-svn: 207038

llvm-svn: 207037

llvm-svn: 207036

GCOV provides an option to prepend output file names with the source
file name, to disambiguate between covered data that's included from
multiple sources. Add a flag to llvm-cov that does the same.

llvm-svn: 207035

llvm-svn: 207034