Add test case for <rdar://problem/10553686>, which illustrates RetainCount checker working with inlined C++ template functions.

llvm-svn: 153069

llvm-svn: 153068

on code using multi-dimensional arrays.  Fix by DeLesley Hutchins, and reported in
PR 12271.

llvm-svn: 153067

1) opt is not usually in the same path as the target program. Even for
the bugpoint as a standalone app, it should be more portable to search
in PATH, isn't it?
2) bugpoint driver accounts opt plugins, but does not list them in the
final output command.

Patch by Dmitry Mikushin!

llvm-svn: 153066

llvm-svn: 153065

llvm-svn: 153064

llvm-svn: 153063

the passed cursor is the translation unit cursor.

Patch by Clint Caywood!

llvm-svn: 153062

Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern
Changes to synthetic children:
 - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points
   this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed
 - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly)
   claim to itself be synthetic
 - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible
 - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself
 - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place)
Some clean ups to the summary generation code
Centralized the code that clears out user-visible strings and data in ValueObject
More efficient summaries for libc++ containers

llvm-svn: 153061

Fixed a case where the source path remappings on the module were too expensive to
use when we try to verify (stat the file system) that the remapped path points to
a valid file. Now we will use the lldb_private::Module path remappings (if any) when
parsing the debug info without verifying that the paths exist so we don't slow down
line table parsing speeds.

llvm-svn: 153059

rdar://11059157

llvm-svn: 153055

rdar://11057160

llvm-svn: 153053

llvm-svn: 153052

llvm-svn: 153051

Also add some documentation.

llvm-svn: 153050

Patch by Weiming Zhao!
This fixes PR12212

llvm-svn: 153049

llvm-svn: 153048

llvm-svn: 153046

instructions have been scheduled. Handy for tracking down scheduler bugs, or
bugs exposed by scheduling.

llvm-svn: 153045

llvm-svn: 153044

declaration and its siblings.

llvm-svn: 153043

I would really like to write the handlers in terms of C++11 atomics.  This would give us the best performance, portablity, and safety tradeoff.  Unfortunately I can not yet do that.  So I've put the desired code in comments, and reverted the handler getters to the slower but safer legacy atomic intrinsics.

llvm-svn: 153041

[asan] don't emit __asan_mapping_offset/__asan_mapping_scale by default -- they are currently used only for experiments

llvm-svn: 153040

I've moved __cxa_terminate_handler, __cxa_unexpected_handler and __cxa_new_handler from the public header cxxabi.h into the private header cxa_handlers.hpp.  During this move I've also moved them from namespace __cxxabiapple into the global namespace.  They are, and have always been extern C and so the namespace (or lack of it) does not affect their ABI.  In general external clients should not reference these symbols.  They are atomic variables and will be changing into C++11 atomic variables in the future.  However for those few clients who really need access to them, their name, mangling, size, alignment and layout will remain stable.  You just may need your own declaration of them.  Include guards have been added to the private header cxa_exception.hpp.  The private header cxa_default_handlers.hpp has been removed and the default handlers are now file-static.  Include guards have been added to the private header cxa_handlers.hpp.

llvm-svn: 153039

llvm-svn: 153038

On Win32 hosts, ';' is used for path separator.

llvm-svn: 153037

Allow libc++ to be built with CMake from within the LLVM tree. The libc++ part is just some renaming as the variable  was already in use, conflicting with something else in the LLVM tree.  Contributed by Ruben Van Boxem.

llvm-svn: 153036

llvm-svn: 153035

This regressed in r152583. Also add a test to make sure it doesn't regress again.

llvm-svn: 153034

X86InstrCompiler.td.
 
It also adds –mcpu-generic to the legalize-shift-64.ll test so the test
will pass if run on an Intel Atom CPU, which would otherwise
produce an instruction schedule which differs from that which the test expects.

llvm-svn: 153033

llvm-svn: 153031

violations I introduced. Also sort some of the instructions to get
a more consistent ordering.

Suggestions on still better / more consistent formatting would be
welcome. I'm actually tempted to use a macro to define all of the
delegate methods...

llvm-svn: 153030

type hierarchy. I wanted to use this for the inline cost rewrite, and
found it was missing.

llvm-svn: 153029

overflow checking multiply intrinsic as well.

Add a test for this, updating the test from grep to FileCheck.

llvm-svn: 153028

llvm-svn: 153027

llvm-svn: 153026

llvm-svn: 153013

llvm-svn: 153012

Thanks to Eli for noticing the discrepancy.

llvm-svn: 153011

[analyzer] Mark a failed-realloc's result as an interesting symbol between the realloc call and the null check, so we get nicer path notes. Fixes a regression introduced by the diagnostic pruning added in r152361.

This is accomplished by calling markInteresting /during/ path diagnostic generation, and as such relies on deterministic ordering of BugReporterVisitors -- namely, that BugReporterVisitors are run in /reverse/ order from how they are added. (Right now that's a consequence of storing visitors in an ImmutableList, where new items are added to the front.) It's a little hacky, but it works for now.

I think this is the best we can do without storing the relation between the old and new symbols, and that would be a hit whether or not there ends up being an error.

llvm-svn: 153010