llvm-svn: 214167

llvm-svn: 214166

llvm-svn: 214165

llvm-svn: 214164

This broke the following gdb tests:

gdb.base__annota1.exp
gdb.base__consecutive.exp
gdb.python__py-symtab.exp
gdb.reverse__consecutive-precsave.exp
gdb.reverse__consecutive-reverse.exp

I will look into this.

This reverts commit 214162.

llvm-svn: 214163

This allows us to give more precise diagnostics.

Diego kindly tested the impact on debug info size: "The increase on average
debug sizes is 0.1%. The total file size increase is ~0%."

llvm-svn: 214162

A piece of a future patch accidentally made it in, this simply
fixes the error.

llvm-svn: 214161

llvm-svn: 214159

llvm-svn: 214158

Fix the sort of expected order in the reader to correctly return `false`
when comparing a `Use` against itself.

This was caught by test/Bitcode/binaryIntInstructions.3.2.ll, so I'm
adding a `RUN` line using `llvm-uselistorder` for every test in
`test/Bitcode` that passes.

A few tests still fail, so I'll investigate those next.

This is part of PR5680.

llvm-svn: 214157

A follow-up commit is adding a RUN line to each of these tests, so fix
the line endings first.  This is a whitespace-only change.

llvm-svn: 214156

llvm-svn: 214155

never present in Clang trunk, but was present in some of my development work,
and it seems like a useful test to have.

llvm-svn: 214154

llvm-svn: 214152

definition in order to apply isa<...>.

llvm-svn: 214151

It was added 12 years ago, but never used (and in the case of sort, never
implemented).

llvm-svn: 214150

llvm-svn: 214149

The -mstrict-align option was originally added in r167619 as a target-
independent option. It was then changed in r167623 to be implemented with an
ARM-specific backend option, even though the code remained in the
target-independent Clang::ConstructJob function. This means that if you used
the -mstrict-align option with a non-ARM target, you would still get the
-arm-strict-align option getting passed to the backend, which was harmless
but gross. The driver option was then replaced by the GCC-compatible
-m[no-]unaligned-access option (r189175) and modified to work with AArch64
(r208075). However, in the process, the help text for -mstrict-align was
incorrectly changed to show it as only being supported for AArch64. Even worse,
the logic for handling these options together with -mkernel was wrong for
AArch64, where -mkernel does not currently imply strict alignment.

This patch fixes up all of those things. Besides the obvious change to the
option help text, it moves the logic into the ARM and AArch64-specific parts
of the driver, so that the option will be correctly ignored for non-ARM
targets. <rdar://problem/17823697>

llvm-svn: 214148

llvm-svn: 214147

llvm-svn: 214146

llvm-svn: 214145

llvm-svn: 214144

to just print the symbol name.  So it matches darwin’s nm(1) -u option.

llvm-svn: 214143

llvm-svn: 214142

This isn't nearly as elaborate as the GCC inline asm which emits an
array of source locations, but it's very, very hard to trigger backend
diagnostics in MS inline asm because we parse it up front with good
source information, unlike GCC inline asm.

Currently I can trigger a "inline assembly requires more registers than
available" diagnostic with this code:

  void foo();
  void bar() {
    __asm pusha
    __asm call foo
    __asm popa
  }

However, if I committed that as a test case, I would have to remove it
once I fix PR20052.

llvm-svn: 214141

All iOS arm processor support switching between arm and thumb mode at call sites
by using the BLX instruction (instead of BL).  But the compiler does not know
the implementation mode for extern functions, so the linker must update BL/BLX
instructions to match what is linked is actually linked together.  In addition,
pointers to functions (such as vtables) must have the low bit set if the target
of the pointer is a thumb mode function.

llvm-svn: 214140

The enum types array by design contains pointers to MDNodes rather than DIRefs.
Unique them when handling the enum types in DwarfDebug.

rdar://17628609

llvm-svn: 214139

This was causing core dumps on MacOSX and was not properly
cleaning up the state of the inferior before exiting.

The test was overriding def tearDown(), but failed to
call the base class after doing its own cleanup.  This
essentially eliminated normal clean-up activity.

llvm-svn: 214138

llvm-svn: 214137

llvm-svn: 214136

Since we're storing lots of these, save two-pointers per vector with a
custom type rather than using the relatively heavy `SmallVector`.

Part of PR5680.

llvm-svn: 214135

This should be covered by the Driver's unit tests.

llvm-svn: 214134

This is the last patch to unique the type array of a subroutine type.
This is the paired commit with llvm r214132.

llvm-svn: 214133

DITypeArray is an array of DITypeRef, at its creation, we will create
DITypeRef (i.e use the identifier if the type node has an identifier).

This is the last patch to unique the type array of a subroutine type.

rdar://17628609

llvm-svn: 214132

We branched 3.5, it's now time to work on 3.6.

This is Sylvestre's patch from [1] plus regenerated configure
file by me, and minus the release notes reset, which Sean
pointed out [2] should happen later.

 1. http://reviews.llvm.org/D4660
 2. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140721/111137.html

llvm-svn: 214131

llvm-svn: 214130

been updating configure.

llvm-svn: 214129

Somehow this wasn't being built before (only noticed now since the test
was XFAILed).

llvm-svn: 214128

Predict and serialize use-list order in bitcode.  This makes the option
`-preserve-bc-use-list-order` work *most* of the time, but this is still
experimental.

  - Builds a full value-table up front in the writer, sets up a list of
    use-list orders to write out, and discards the table.  This is a
    simpler first step than determining the order from the various
    overlapping IDs of values on-the-fly.

  - The shuffles stored in the use-list order list have an unnecessarily
    large memory footprint.

  - `blockaddress` expressions cause functions to be materialized
    out-of-order.  For now I've ignored this problem, so use-list orders
    will be wrong for constants used by functions that have block
    addresses taken.  There are a couple of ways to fix this, but I
    don't have a concrete plan yet.

  - When materializing functions lazily, the use-lists for constants
    will not be correct.  This use case is out of scope: what should the
    use-list order be, if it's incomplete?

This is part of PR5680.

llvm-svn: 214125

llvm-svn: 214124