llvm-svn: 117615

llvm-svn: 117613

version);  change include statements to use Python.h in the Python framework
on Mac OS X systems; leave it using regular Python.h on other systems.

Note:  I think this *ought* to work properly on Linux systems, but I don't have
a system to test it on...

llvm-svn: 117612

t.s:1:14: error: invalid operand for instruction
vldr.64	d17, [r0]   
       	     ^

instead of:

t.s:1:1: error: unrecognized instruction
vldr.64	d17, [r0]   
^

llvm-svn: 117611

using the memory type;  fixes an assert.

Fixes rdar://problem/8605032

llvm-svn: 117610

the opcode string in the inst dump, e.g.:
	vmov	r2, r3, d17             @ encoding: [0x31,0x2b,0x53,0xec]
                                        @ <MCInst #989 VMOVRRD
                                        @  <MCOperand Reg:68>
                                        @  <MCOperand Reg:69>
                                        @  <MCOperand Reg:19>
                                        @  <MCOperand Imm:14>
                                        @  <MCOperand Reg:0>>

The "VMOVRRD" is new.

llvm-svn: 117609

* If we have a M or a G, reject sections without the type
* Only parse the flag specific arguments if we have M or G
* Parse the corresponding arguments for M and G

We ignore the G arguments and flag for now.

llvm-svn: 117608

it looks like we're not handling [] operands though

llvm-svn: 117607

(like ARM) correctly.  With this change, we can now match "bx lr"
because we recognize lr as a register.

llvm-svn: 117606

llvm-svn: 117605

llvm-svn: 117604

llvm-svn: 117603

llvm-svn: 117602

llvm-svn: 117601

llvm-svn: 117600

in SSAUpdaterImpl.h

Verifying live intervals revealed that the old method was completely wrong, and
we need an iterative approach to calculating PHI placemant. Fortunately, we have
MachineDominators available, so we don't have to compute that over and over
like SSAUpdaterImpl.h must.

Live-out values are cached between calls to mapValue() and computed in a greedy
way, so most calls will be working with very small block sets.

Thanks to Bob for explaining how this should work.

llvm-svn: 117599

proper SSA updating.

This doesn't cause MachineDominators to be recomputed since we are already
requiring MachineLoopInfo which uses dominators as well.

llvm-svn: 117598

split.

llvm-svn: 117597

which contains slashes is inconsistent with the meaning of PATH on
Unix-type platforms, and pretty surprising.

If the user has given a specific path to execute and we can't
execute it, we should fail and say why.  (Apparently the new
posix_spawn code doesn't always say why, but that's a separate
issue.)

llvm-svn: 117596

llvm-svn: 117595

llvm-svn: 117592

llvm-svn: 117588

llvm-svn: 117586

llvm-svn: 117585

llvm-svn: 117584

llvm-svn: 117583

Original commit message:

    On "Unix", if Program::FindProgramByName is given a name containing
    slashes, just go with it, regardless of whether it looks like it will
    be executable. This follows the behavior of sh(1) more closely.

It's better when behaviour is consistent between platforms. This change also
makes FindExecutable() behave as expected on unix-likes (before this commit, it
used to always succeed).

llvm-svn: 117582

llvm-svn: 117581

llvm-svn: 117580

llvm-svn: 117577

llvm-svn: 117576

llvm-svn: 117575

familiar with the ownership relationships
involving Diagnostic.

llvm-svn: 117573

llvm-svn: 117572

llvm-svn: 117571

Move the existing patching for undefined symbols so that all the patching
is done in the same function.

llvm-svn: 117570

If TestBase.expect() is passed an assert message, pass it along when delegating to TestBase.runCmd()
to execute the debugger command.  This will result in a more semantic assert message than just the
command failed message like before:

AssertionError: False is not True : Command 'thread list' returns successfully

And now, we will have:

AssertionError: False is not True : Process state is stopped due to breakpoint
llvm-svn: 117569

logging for type importing, making errors much
easier to diagnose.  Also removed some Objective-C
related logging.

llvm-svn: 117568

Part 2 of rdar://problem/8595231

llvm-svn: 117567

llvm-svn: 117563