llvm-svn: 153502

last N months.  This required a brief soliloquy about change in
an uncertainly-versioned world.

I believe I've gotten the right target versions on all these changes.

llvm-svn: 153501

llvm-svn: 153500

MachinePointerInfo when getStore is called to create a node that stores an
argument passed in register to the stack. Without this change, the post RA 
scheduler will fail to discover the dependencies between the stores
instructions and the instructions that load from a structure passed by value. 

The link to the related discussion is here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-March/048055.html

llvm-svn: 153499

llvm-svn: 153498

llvm-svn: 153497

1 - sections only get a valid VM size if they have SHF_ALLOC in the section flags
2 - symbol names are marked as mangled if they start with "_Z"

Also fixed the DWARF parser to correctly use the section file size when extracting the DWARF.

llvm-svn: 153496

Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available.
A new setting enable-synthetic-value is provided on the target to disable this behavior.
There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic.
The test suite has been changed accordingly.
Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang
Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching

llvm-svn: 153495

set it in MipsMCCodeEmitter::getMachineOpValue. Assert in getMachineOpValue if
MachineOperand MO is of an unexpected type. 

llvm-svn: 153494

offset applied to it.

llvm-svn: 153493

register that's read by the preheader terminator.

rdar://11095580

llvm-svn: 153492

cleared. No functionality change.

llvm-svn: 153491

isConstructorDeclaration also needs updating for any extension to the
grammar of a direct-declarator.

llvm-svn: 153490

assigned to a struct.  This is fallout from inlining results, which expose
far more patterns where people stuff CF objects into structs and pass them
around (and we can reason about it).  The problem is that we don't have
a general way to detect when values have escaped, so as an intermediate step
we need to eagerly prune out such tracking.

Fixes <rdar://problem/11104566>.

llvm-svn: 153489

constructor, but X is not a known typename, check whether the tokens could
possibly match the syntax of a declarator before concluding that it isn't
a constructor. If it's definitely ill-formed, assume it is a constructor.

Empirical evidence suggests that this pattern is much more often a
constructor with a typoed (or not-yet-declared) type name than any of the
other possibilities, so the extra cost of the check is not expected to be
problematic.

llvm-svn: 153488

copies being considered for removal. Make sure to track all of the copies,
rather than just the most recent encountered, by holding a DenseSet instead of
an unsigned in SrcMap.

No test case - couldn't reduce something with a sane size.

llvm-svn: 153487

llvm-svn: 153486

We don't currently support these options.
rdar://11120518

llvm-svn: 153485

produces a 32-bit immediate which is consumed by the use. It tries to 
fold the immediate by breaking it into two parts and fold them into the
immmediate fields of two uses. e.g
       movw    r2, #40885
       movt    r3, #46540
       add     r0, r0, r3
=>
       add.w   r0, r0, #3019898880
       add.w   r0, r0, #30146560
;
However, this transformation is incorrect if the user produces a flag. e.g.
       movw    r2, #40885
       movt    r3, #46540
       adds    r0, r0, r3
=>
       add.w   r0, r0, #3019898880
       adds.w  r0, r0, #30146560
Note the adds.w may not set the carry flag even if the original sequence
would.

rdar://11116189

llvm-svn: 153484

llvm-svn: 153483

Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482

llvm-svn: 153481

Fixes PR11882: NULL dereference in ComputeLoadConstantCompareExitLimit.

llvm-svn: 153480

llvm-svn: 153479

1. Don't short-circuit conditional statements that are checking flags.
Otherwise, the driver emits warnings about unused arguments.

2. -mkernel and -fapple-kext imply no exceptions, so claim exception related
 arguments now to avoid warnings about unused arguments.

rdar://11120518

llvm-svn: 153478

If creation of watchpoint failed on the device, make sure the list maintained by the target reflects that by cleaning it up.

llvm-svn: 153477

Patch by Ojab.

llvm-svn: 153476

llvm-svn: 153472

backtrace locations.

Testcase forthcoming, but I wanted to get some testing here.

Should fix:

PR12323
PR12314
rdar://11091100

llvm-svn: 153471

argument warning.
Part of rdar://11120518

llvm-svn: 153470

argument warning.
Part of rdar://11120518

llvm-svn: 153469

153465 was incorrect. In this code we wanted to check that the pointer operand is of pointer type (and not vector type).

llvm-svn: 153468

Patched LLVM to handle generic i386 relocations.
This avoids some sudden termination problems on
i386 where the JIT would exit() out reporting
"Invalid CPU type!"

llvm-svn: 153467

relocations.  The algorithm is the same as
that for x86_64.  Scattered relocations, a
feature present in i386 but not on x86_64,
are not yet supported.

llvm-svn: 153466

llvm-svn: 153465

between unscoped enumerations and class template member specializations,
whose behavior is currently under discussion in CWG (and for which there
is a preference to not implement the currently-standardized wording).

llvm-svn: 153464

Fixes PR11950.

llvm-svn: 153463

llvm-svn: 153462

unscoped enumeration members: an enumerator name which is visible in the
out-of-class definition of a member of a templated class might not actually
exist in the instantiation of that class, if the enumeration is also lexically
defined outside the class definition and is explicitly specialized.

Depending on the result of a CWG discussion, we may have a different resolution
for a class of problems in this area, but this fixes the immediate issue of a
crash-on-invalid / accepts-invalid (depending on +Asserts). Thanks to Johannes
Schaub for digging into the standard wording to find how this case is currently
specified to behave.

llvm-svn: 153461

llvm-svn: 153460