undefined result. This adds new ISD nodes for the new semantics,
selecting them when the LLVM intrinsic indicates that the undef behavior
is desired. The new nodes expand trivially to the old nodes, so targets
don't actually need to do anything to support these new nodes besides
indicating that they should be expanded. I've done this for all the
operand types that I could figure out for all the targets. Owners of
various targets, please review and let me know if any of these are
incorrect.

Note that the expand behavior is *conservatively correct*, and exactly
matches LLVM's current behavior with these operations. Ideally this
patch will not change behavior in any way. For example the regtest suite
finds the exact same instruction sequences coming out of the code
generator. That's why there are no new tests here -- all of this is
being exercised by the existing test suite.

Thanks to Duncan Sands for reviewing the various bits of this patch and
helping me get the wrinkles ironed out with expanding for each target.
Also thanks to Chris for clarifying through all the discussions that
this is indeed the approach he was looking for. That said, there are
likely still rough spots. Further review much appreciated.

llvm-svn: 146466

validates the "self," "this," and "_cmd" pointers
that get passed into expressions.  It used to check
them aggressively for validity before allowing the
expression to run as an object method; now, this
functionality is gated by a bool and off by default.

Now the default is that when LLDB is stopped in a
method of a class, code entered using "expr" will
always masquerade as an instance method.  If for
some reason "self," "this," or "_cmd" is unavailable
it will be reported as NULL.  This may cause the
expression to crash if it relies on those pointers,
but for example getting the addresses of ivars will
now work as the user would expect.

llvm-svn: 146465

llvm-svn: 146463

Modified the Xcode project to not strip liblldb-core.a for BuildAndIntegration builds
and to correctly strip only debug symbols from the command line binaries.

llvm-svn: 146462

llvm-svn: 146461

llvm-svn: 146459

Constant pool entries with different alignment may cause more alignment
padding to be inserted. Compute the amount of padding needed, and try to
pick the location that requires the least amount of padding.

Also take the extra padding into account when the water is above the
use.

llvm-svn: 146458

llvm-svn: 146457

llvm-svn: 146456

llvm-svn: 146455

llvm-svn: 146454

llvm-svn: 146453

llvm-svn: 146451

llvm-svn: 146448

Necessary to parse Microsoft ATL code.

Example: 
  int array[] = {
    0, 
    __if_exists(CLASS::Type) {2, }
    3
  };

will declare an array of 2 or 3 elements depending on if CLASS::Type exists or not.

llvm-svn: 146447

llvm-svn: 146446

llvm-svn: 146445

inside a struct/union.

llvm-svn: 146444

Make CGRecordLayoutBuilder correctly switch over to a packed class when a class has a base whose alignment will break the class layout.  <rdar://problem/10551376>.

llvm-svn: 146443

llvm-svn: 146442

llvm-svn: 146441

llvm-svn: 146440

then read the file back in to verify use-list serialization/deserialization.

llvm-svn: 146439

This should always be done as a matter of principal. I don't have a
case that exposes the problem. I just noticed this recently while
scanning the code and realized I meant to fix it long ago.

llvm-svn: 146438

autodiscovery.

llvm-svn: 146437

subdirectories to traverse into.
 - Originally I wanted to avoid this and just autoscan, but this has one key
   flaw in that new subdirectories can not automatically trigger a rerun of the
   llvm-build tool. This is particularly a pain when switching back and forth
   between trees where one has added a subdirectory, as the dependencies will
   tend to be wrong. This will also eliminates FIXME implicitly.

llvm-svn: 146436

llvm-svn: 146435

--write-llvmbuild.

llvm-svn: 146434

llvm-svn: 146433

-relocation-model=static.

llvm-svn: 146432

llvm-svn: 146431

The motivation here is a "clever" implementation of strncmp(), which peels the first few comparisons via chained conditional expressions which ensure that the input arrays are known at compile time to be sufficiently large.

llvm-svn: 146430

llvm-svn: 146429

If we create new intervals for a variable that is being spilled, then those new intervals are not guaranteed to also spill.  This means that anything reading from the original spilling value might not get the correct value if spills were missed.

Fixes <rdar://problem/10546864>

llvm-svn: 146428

with the recent clang compilers.

The latest I tried is: Apple clang version 3.1 (tags/Apple/clang-318.0.9) (based on LLVM 3.1svn)

llvm-svn: 146427

There were two problems associated with this radar:
1. "settings show target.source-map" failed to show the source-map after, for example,
   "settings set target.source-map /Volumes/data/lldb/svn/trunk/test/source-manager /Volumes/data/lldb/svn/trunk/test/source-manager/hidden"
   has been executed to set the source-map.
2. "list -n main" failed to display the source of the main() function after we properly set the source-map.

The first was fixed by adding the missing functionality to TargetInstanceSettings::GetInstanceSettingsValue (Target.cpp)
and updating the support files PathMappingList.h/.cpp; the second by modifying SourceManager.cpp to fix several places
with incorrect logic.

Also added a test case test_move_and_then_display_source() to TestSourceManager.py, which moves main.c to hidden/main.c,
sets target.source-map to perform the directory mapping, and then verifies that "list -n main" can still show the main()
function.

llvm-svn: 146422

llvm-svn: 146420

it is not required.

llvm-svn: 146418

These modifiers simply select either the low or high D subregister of a Neon
Q register.  I've also removed the unimplemented 'p' modifier, which turns out
to be a bit different than the comment here suggests and as far as I can tell
was only intended for internal use in Apple's version of gcc.

llvm-svn: 146417

fields by just following what comment says.
// rdar://10513599

llvm-svn: 146414