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

llvm-svn: 168141

finally was able to restore a register, instead of just reporting the
frames that couldn't supply the reg.

llvm-svn: 168139

llvm-svn: 168138

llvm-svn: 168137

it as a pointer. 

llvm-svn: 168136

llvm-svn: 168135

Revert r168132, "clang/test/lit.cfg: Suppress the feature 'dev-fd-fs' for now." I missed Daniel's r168095 by my accident.

llvm-svn: 168134

to the CodeCompletionTUInfo that is going to be used to get the results.

Previously we would use ASTUnit's CodeCompletionTUInfo which has its own allocator
that will go away when we reparse. That could result in a use-after-free bug when
getting the parent context name from a CodeCompletionString.

Addresses rdar://12568377.

llvm-svn: 168133

None of my buildhost (centos6 x86-64 and cygwin) is passing. Investigating.

llvm-svn: 168132

allowed in branch delay slot.

llvm-svn: 168131

 - This diverges from gcc, and confuses tools (like dtrace) which track # line
   markers as a way to determine which content is in the context of the main
   file.

llvm-svn: 168128

width of an enum with negative values in IntRange.  Include a test for
-Wtautological-constant-out-of-range-compare where this had manifested.

llvm-svn: 168126

GCC 4.7 reuses stack slots fairly aggressively, which exposes more temporary
lifetime bugs.

No new test, this was caught by the existing CodeGenCXX/mangle-ms-templates.cpp.

llvm-svn: 168124

allowed volatile registers to be returned up the stack.  That leads
to unexpected/incorrect values provided to the user and we need to
avoid that.
<rdar://problem/12714247>

llvm-svn: 168123

llvm-svn: 168121

Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.

No functionality changes are intended here (they will come when the predicates
start producing the right answers...).

llvm-svn: 168119

llvm-svn: 168118