llvm-svn: 121410

a bug in Apple GCC 4.0.

llvm-svn: 121409

Fix an issue in some Thumb fixups, where the effective PC address needs to be 4-byte aligned when calculating
the offset.  Add a new fixup flag to represent this, and use it for the one fixups that I have a testcase for needing
this.  It's quite likely that the other Thumb fixups will need this too, and to have their fixup encoding logic
adjusted accordingly.

llvm-svn: 121408

llvm-svn: 121404

This test intends to catch invalid use of ".byte 256" in output. Now, the assert in MC will be triggered in such cases.

llvm-svn: 121403

llvm-svn: 121402

the condition codes.  Where the ones that do have an 's' suffix and the ones
that don't don't have the suffix.  The trick is if MatchInstructionImpl() fails
we try again after adding a CCOut operand with the correct value and removing
the 's' if present.  Four simple test cases added for now, lots more to come.

llvm-svn: 121401

llvm-svn: 121399

t_brtarget to be more specific.

llvm-svn: 121398

The sensible thing would be to have these intrinsics take all quad-register
vector operands, but that's not what ARM did.  They made the last vector
operand always be a double-register type.  Since the lane number
must be a constant, the user can know which half of a quad-register contains
that lane, extract the high or low half of the vector, and adjust the lane
number accordingly.  The only advantage I can see for this is that it works
better when you want to multiply a quad-register value by a lane from a
double-register value, but I wouldn't have expected that to be the common
case.  Oh well -- at this point we just need to follow the spec.

llvm-svn: 121397

process launch now asks to kill the current process if it is alive, and if you affirm, does so for you.
Also added #pragma mark for the command objects defined in the file.

llvm-svn: 121396

llvm-svn: 121395

llvm-svn: 121393

Their suffixes are supposed to reflect the source operand element type,
not the destination element type.  Radar 8746481.

llvm-svn: 121392

Otherwise, a plain str/ldr should be used instead. Make sure we account for
that in prologue/epilogue code generation.
rdar://8745460

llvm-svn: 121391

Remove the previous header.  I don't think we need to expose to end users
that we use TableGen to produce our version of arm_neon.h, and that header
was also using doubleslash comments which could be a problem when using it
in strict C89 compilations.

llvm-svn: 121390

Initial test case test_modify_source_file_while_debugging() in TestSourceManager.py
tests the caching mechanism of the source manager.

llvm-svn: 121389

heuristic to reshuffle register assignments when we can't find an
available reg.

llvm-svn: 121388

llvm-svn: 121387

llvm-svn: 121386

llvm-svn: 121385

llvm-svn: 121383

llvm-svn: 121382

templated c_str in Windows.h to replace it.

llvm-svn: 121381

return their result instead of an error_code. Also add some missing predicate
functions.

llvm-svn: 121380

llvm-svn: 121379

llvm-svn: 121378

llvm-svn: 121377

llvm-svn: 121376

"inline", we weren't giving the definition weak linkage because the
"inline" bit wasn't propagated. This was a longstanding FIXME that,
somehow, hadn't triggered a bug in the wild. Fix this problem by
tracking whether any declaration was marked "inline", and clean up the
semantics of GNU's "extern inline" semantics calculation based on this
change.

Fixes <rdar://problem/8740363>.

llvm-svn: 121373

llvm-svn: 121372

llvm-svn: 121371

llvm-svn: 121370

llvm-svn: 121363

llvm-svn: 121362

substitution because it doesn't actually change the IR.  Patch by
Jakub Staszak!

llvm-svn: 121361

Radar 8446277c.

llvm-svn: 121360

Radar 8446277c.

llvm-svn: 121359

the output to the correct register. Fixes a hidden problem uncovered
by the last patch where we'd try to DAG combine our MVT::Other node
oddly.

llvm-svn: 121358

llvm-svn: 121357