This fixes PR14359

llvm-svn: 168200

An alias to a function should use pc relative addressing.

llvm-svn: 168199

llvm-svn: 168198

Before, the parser would assert on the following code:

@a2 = global i8 addrspace(1)* @a
@a = addrspace(1) global i8 0

because the type of @a was "i8*" instead of "i8 addrspace(1)*" when parsing
the initializer for @a2.

llvm-svn: 168197

llvm-svn: 168196

llvm-svn: 168195

llvm-svn: 168191

Removed an assert that was for debug only.

llvm-svn: 168190

ReleaseNotes.html updates reflecting PPC64 Elf Linux efforts and progress.

llvm-svn: 168189

but wasn't due to the same logic bug that caused PR14361.

llvm-svn: 168186

A PR is being filed to address some code issues here.

llvm-svn: 168185

made in upstream llvm (r168114)

llvm-svn: 168184

llvm-svn: 168183

llvm-svn: 168182

replaced by this patch is equivalent to the new logic, but you'd be wrong, and
that's exactly where the bug was.  There's a similar bug in instsimplify which
manifests itself as instsimplify failing to simplify this, rather than doing it
wrong, see next commit.

llvm-svn: 168181

llvm-svn: 168180

llvm-svn: 168178

The problem is that a partial match of an (explicit or implicit) allOf matcher
binds results, i.e.

recordDecl(decl().bind("x"), hasName("A"))

can very well bind a record that is not named "A". With this fix, the common
cases of stumbling over this bug are fixed by the BoundNodesMap overwriting the
results of a partial match. An error can still be created with a weird
combination of anyOf and allOf (see inactive test). We need to decide whether
this is worth fixing, as the fix will have performance impact.

Review: http://llvm-reviews.chandlerc.com/D124
llvm-svn: 168177

Patch by Pekka Jääskeläinen!

llvm-svn: 168176

This has been broken for a while, but the branch was never being taken.
(We were trying to do 'str + floatVal'; now we do 'str % intVal' and use
the '%d' format.)

llvm-svn: 168174

Technically this is still a layering violation but it's header-only which makes
it less harmful. No functionality change.

llvm-svn: 168173

LLVM_USED_LIBS does nothing here.

llvm-svn: 168172

llvm-svn: 168171

llvm-svn: 168170

UBSan: enable CMake build on Darwin. Fix two failing tests and disable the test which produces linker errors on Darwin.

llvm-svn: 168169

UBSan: enable proper linking with UBsan runtime on Darwin. Turn on building ubsan on OS X in 'make' build system. Patch by Jean-Daniel Dupas.

llvm-svn: 168168

llvm-svn: 168167

llvm-svn: 168166

email address for completeness.

llvm-svn: 168165

Notably, I'm reviewing this stuff already, and this makes it clear I'm
on the hook for it.

I'm relying on Eric Christopher and Michael Spencer to help with Support
when there are platform specific issues, but Chris wants a single point
of contact, and I'm happy with that.

llvm-svn: 168164

llvm-svn: 168151

llvm-svn: 168150

llvm-svn: 168149

all symbols during object loading, not just global ones.

This fixes JIT execution of code using llvm.global_ctors with internal
linkage constructors.

llvm-svn: 168148

It turns out that the operands of a Constant are not always themselves
Constant. For example, one of the operands of BlockAddress is
BasicBlock, which is not a Constant.

This should fix the dragonegg-x86_64-linux-gcc-4.6-test build which
broke in r168037.

llvm-svn: 168147

llvm-svn: 168146

llvm-svn: 168145

[DebugInfo] Generate address ranges for compile units even if .debug_aranges is present: it is often the case that .debug_aranges section contains ranges only for a small subset of compile units. Test cases will be added in separate commits.

llvm-svn: 168144

llvm-svn: 168143

LoopVectorize: Division reductions generate incorrect code. Remove the part of the code that deals with divs.
Thanks to Paul Redmond for catching this while reviewing the code.

llvm-svn: 168142