This modifies BugReporter and friends to handle CallEnter and CallExitEnd
program points that came from implicit call CFG nodes (read: destructors).

This required some extra handling for nested implicit calls. For example,
the added multiple-inheritance test case has a call graph that looks like this:

testMultipleInheritance3
  ~MultipleInheritance
    ~SmartPointer
    ~Subclass
      ~SmartPointer
        ***bug here***

In this case we correctly notice that we started in an inlined function
when we reach the CallEnter program point for the second ~SmartPointer.
However, when we reach the next CallEnter (for ~Subclass), we were
accidentally re-using the inner ~SmartPointer call in the diagnostics.

Rather than guess if we saw the corresponding CallExitEnd based on the
contents of the active path, we now just ask the PathDiagnostic if there's
any known stack before popping off the top path.

(A similar issue could have occured without multiple inheritance, but there
wasn't a test case for it.)

llvm-svn: 160804

At the very least this means initializer nodes for constructors and
automatic object destructors are present in the CFG.

llvm-svn: 160803

This avoids an assertion crash when we invalidate on a destructor call
instead of inlining it.

llvm-svn: 160802

llvm-svn: 160801

Fallout from CmpRuns.py API changes in r160314.

llvm-svn: 160800

Patch by Andrew C. Morrow:  shims to work around macroized getc and putc on linux.  On my eglibc 2.13 based Debian system 'getc' is a macro defined in
/usr/include/stdio.h. This decision to make it a macro doesn't seem to
be guarded by any feature test macro as far as I can see.

llvm-svn: 160799

llvm-svn: 160798

llvm-svn: 160797

This is still a work in progress.

Out-of-order CPUs usually execute instructions from multiple basic
blocks simultaneously, so it is necessary to look at longer traces when
estimating the performance effects of code transformations.

The MachineTraceMetrics analysis will pick a typical trace through a
given basic block and provide performance metrics for the trace. Metrics
will include:

- Instruction count through the trace.
- Issue count per functional unit.
- Critical path length, and per-instruction 'slack'.

These metrics can be used to determine the performance limiting factor
when executing the trace, and how it will be affected by a code
transformation.

Initially, this will be used by the early if-conversion pass.

llvm-svn: 160796

Relax the test for "is the frame I am going to step back out to the one I started from" in ThreadPlanStepOverRange so you don't
artificially reject stepping out of a function you stepped into when stepping through an inlined range.  

Also fill in the target in the symbol context we make up for the inlined stepping range in ThreadPlanStepOut.

<rdar://problem/11765912>

llvm-svn: 160794

llvm-svn: 160791

Patch by Andrew C. Morrow:  Conditionally include cxxabi.h in new.cpp and typeinfo.cpp.  Both new.cpp and typeinfo.cpp have code that is conditionally compiled
based on the LIBCXXRT and _LIBCPPABI_VERSION defines, but those files
do not currently include <cxxabi.h> in the non __APPLE__ case. The
attached patch updates those files so that for non __APPLE__ builds
<cxxabi.h> is included if available or if LIBCXXRT is set. I'm
modeling this on the recent updates to exception.cpp.

llvm-svn: 160790

is missing in method prototype. // rdar://11939584

llvm-svn: 160789

Put back dump() without a default argument, "because debuggers don't usually respect default arguments".

llvm-svn: 160788

Thanks Eli for noticing.

llvm-svn: 160787

<algorithm> no longer needs to include <cstdlib>, but can get away with just <cstddef>.  This was brought to my attention by Salvatore Benedetto in his port to a bare-metal coretex-m3.  This exposed two test bugs where an explicit #include <cstdlib> was needed.

llvm-svn: 160786

llvm-svn: 160785

llvm-svn: 160784

llvm-svn: 160783

Add more tests for PR13207 (Mangling of template back references with -cxx-abi microsoft) now that PR13389 is fixed (mangling of return types)

llvm-svn: 160782

llvm-svn: 160780

is a temporary measure until my fix for PR13021 is ready.

llvm-svn: 160778

llvm-svn: 160777

hopefully make it more visible.  Adjust the web-docs to have a link to
this file rather than the list itself.  I described code owners as also
being gatekeepers for their part of the code, which I think is true but
isn't in the code owner explanation on the web page.

llvm-svn: 160776

llvm-svn: 160775

Patch by Reed Kotler.

llvm-svn: 160774

platform-provided macro on some systems) to _LIBCPP_NORETURN.

llvm-svn: 160773

llvm-svn: 160772

llvm-svn: 160770

corrected the offsets for x86_64 conditional
branch instructions.

<rdar://problem/11502148>

llvm-svn: 160769

- Some cleanup(the TODOs) will be done after ObjC method inlining is
complete.
- Simplified CallEvent::getDefinition not to require ISDynamicDispatch
parameter.
- Also addressed Jordan's comments from r160530.

llvm-svn: 160768

llvm-svn: 160767

llvm-svn: 160766

llvm-svn: 160764

llvm-svn: 160763

llvm-svn: 160762

llvm-svn: 160761

value by scanning the path, rather than assuming we have visited the '?:' operator
as a terminator (which sets a value indicating which expression to grab the
final ternary expression value from).

llvm-svn: 160760

"memset' lazily when is needed in translation of
struct-valued methods which require checkinf of nil receivers
outside their bodies. // rdar://11847319

llvm-svn: 160759

This simplifies MCRegisterInfo and shrinks the target descriptions a bit
more.

llvm-svn: 160758