Ensure that lldb/runtime is not a dead point in the Python package hierarchy - This is a first preliminary step in fixing data formatters after Greg's changes to the Python resources on-disk layout

llvm-svn: 155525

llvm-svn: 155524

llvm-svn: 155523

llvm-svn: 155522

llvm-svn: 155521

llvm-svn: 155520

llvm-svn: 155519

llvm-svn: 155517

llvm-svn: 155516

ObjCPlusPlus as Objective-C classes.  Really the
compiler should say they have Objective-C runtime
class, but we should be a little more resilient
(we were refusing to find ivars in those classes
before).

Also added a test case.

llvm-svn: 155515

Enrico will follow this up with fixing the data formatter test cases that are failing.

llvm-svn: 155514

of a precise count. Also, move RRInfo's Partial field into PtrState,
now that it won't increase the size.

llvm-svn: 155513

the same test to be run multiple times in the same
session.

llvm-svn: 155511

llvm-svn: 155510

if the section is marked as encrypted.  It will likely be readable
in live memory.
<rdar://problem/11305675>

llvm-svn: 155509

A test for this is checking if this compiles:

    #include <float.h>

    inline bool IsFinite(const double& number) {
     return _finite(number) != 0;
    }

That depends however on either mingw or msvc being installed, and
chapuni tells me there might be issues with float.h on mingw, so
no automated test is added.

llvm-svn: 155507

rdar://problem/11312971

llvm-svn: 155505

test whether an object responds to a selector
from outside the process.

llvm-svn: 155504

case so that the Objective-C runtime doesn't
complain about lack of one, causing the test case
to fail.

llvm-svn: 155503

math library functions.
rdar://11251464

llvm-svn: 155502

llvm-svn: 155501

These lists exclude invoke unwind edges and loop backedges which
are being ignored. This makes it easier to ignore them
consistently.

llvm-svn: 155500

When an instruction match is found, but the subtarget features it
requires are not available (missing floating point unit, or thumb vs arm
mode, for example), issue a diagnostic that identifies what the feature
mismatch is.

rdar://11257547

llvm-svn: 155499

With -fno-math-errno (the default for Darwin) or -ffast-math these library 
function can be marked readnone enabling more opportunities for CSE and other
optimizations.
rdar://11251464

llvm-svn: 155498

llvm-svn: 155497

Fixing an issue where the expression parser was not correctly freeze-drying bitfields - This patch ensures that (a) freeze-drying bitfields works correctly and (b) that we actually access bitfields through IR instead of the 'frame var en lieu of expr' shortcut, for added safety in corner cases that may arise

llvm-svn: 155494

llvm-svn: 155492

Add a '-R' option, which is similar to '-r', except that the relocated directory, if exists, will be removed entirely
before running the test suite.  A usage example looks like this:

test $ ./dotest.py -A x86_64 -R /tmp/x86_64 &
test $ ./dotest.py -A i386 -R /tmp/i386 &

where we would want to run the x86_64 and i386 archs concurrently but relocate the test suite to different directory
hierarchies in order not to stump on each other's intermediate files.

llvm-svn: 155491

Fixes the two issues mentioned in PR12146.

llvm-svn: 155490

Fixed an issue that would happen when using debug map with DWARF in the .o files where we wouldn't ever track down the actual definition for a type when things were in namespaces. We now serialize the decl context information into an intermediate format which allows us to track down the correct definition for a type regardless of which DWARF symbol file it comes from. We do this by creating a "DWARFDeclContext" object that contains the DW_TAG + name for each item in a decl context which we can then use to veto potential accelerator table matches. For example, the accelerator tables store the basename of the type, so if you have "std::vector<int>", we would end up with an accelerator table entry for the type that contained "vector<int>", which we would then search for using a DWARFDeclContext object that contained:

  [0] DW_TAG_class_type "vector<int>"
  [1] DW_TAG_namespace "std"

This is currently used to track down forward declarations for things like "class a::b::Foo;". 

llvm-svn: 155488

templates. In an implicit instantiation of a member class, any member
templates don't get instantiated, so the existing check which only visited
the instantiations of a defined template skipped these templates'
instantiations.

Since there is only a single declaration of a member template of a class
template specialization, just use that to determine whether to visit the
instantiations. This introduces a slight inconsistency in that we will
visit the instantiations of such templates whether or not they are
defined, but we never visit a declared-but-not-defined instantiation, so
this turns out to not matter.

Patch by Daniel Jasper!

llvm-svn: 155487

llvm-svn: 155486

Fix 12592. Patch by Matt Pharr.

llvm-svn: 155480

llvm-svn: 155477

llvm-svn: 155475

declaration of __block variables on same lines
with initializers. // rdsr://7547630

llvm-svn: 155473

MachineBasicBlock::SplitCriticalEdge() should follow LLVM IR variant and refuse to break edge to EH landing pad. rdar://11300144

llvm-svn: 155470

<rdar://problem/11291436>.

llvm-svn: 155468

constants in C++11 mode. I have no idea why it required such particular
circumstances to get here, the code seems clearly to rely upon unchecked
assumptions.

Specifically, when we decide to form an index into a struct type, we may
have gone through (at least one) zero-length array indexing round, which
would have left the offset un-adjusted, and thus not necessarily valid
for use when indexing the struct type.

This is just an canonicalization step, so the correct thing is to refuse
to canonicalize nonsensical GEPs of this form. Implemented, and test
case added.

Fixes PR12642. Pair debugged and coded with Richard Smith. =] I credit
him with most of the debugging, and preventing me from writing the wrong
code.

llvm-svn: 155466

r154362 was supposed to delete this bit, but obviously didn't.

rdar://11305594

llvm-svn: 155465