llvm-svn: 119547

llvm-svn: 119546

llvm-svn: 119545

llvm-svn: 119544

nonofragile-abi2. Fixes //rdar://8673791

llvm-svn: 119543

llvm-svn: 119542

llvm-svn: 119541

llvm-svn: 119540

llvm-svn: 119539

llvm-svn: 119538

llvm-svn: 119537

instructions out of InstCombine and into InstructionSimplify.  While
there, introduce an m_AllOnes pattern to simplify matching with integers
and vectors with all bits equal to one.

llvm-svn: 119536

assert(a || b && "bad");

since this is safe. This way we avoid a big source of such warnings which in this case are practically useless.

Note that we don't handle *all* cases where precedence wouldn't matter because of constants since
this is a bit costly to check, and IMO clarifying precedence with parentheses is good for
readability in general.

llvm-svn: 119533

Put warn_logical_and_in_logical_or warning in new warning group "logical-op-parentheses" member of "parentheses".

llvm-svn: 119532

llvm-svn: 119529

llvm-svn: 119522

llvm-svn: 119518

on a non-type declaration, as GCC permits it on variables too.
This fixes PR8635.

llvm-svn: 119517

an implicit "this"; it causes clang_getCursor() to find the implicit
"this" expression (which isn't written in the source!) rather than the
actual member.

llvm-svn: 119516

llvm-svn: 119515

interest (e.g., as used by clang_getCursor()), count the
decl-specifier-seq as part of the source range, as we do for
clang_annotateTokens(). Makes clang_getCursor() work properly for the
result types of functions, for example.

llvm-svn: 119514

llvm-svn: 119512

Fixes PR8631.

llvm-svn: 119511

 - No immediate use, but maybe someone feels like hacking on it.

llvm-svn: 119510

llvm-svn: 119509

llvm-svn: 119508

Fixes PR8607.

llvm-svn: 119498

hasConstantValue.  I was leery of using SimplifyInstruction
while the IR was still in a half-baked state, which is the
reason for delaying the simplification until the IR is fully
cooked.

llvm-svn: 119494

phi node itself if it occurs in an unreachable basic block.  Protect
against this.  Hopefully this will fix some more buildbots.

llvm-svn: 119493

llvm-svn: 119492

llvm-svn: 119491

simplified to itself (this can only happen in unreachable blocks).
Change it to return null instead.  Hopefully this will fix some
buildbot failures.

llvm-svn: 119490

of all the lines of the inline asm.  With the refactoring and enhancement
of the backend, we can now reports errors on the correct source line when
an asm contains multiple lines of text.  For something like this:

void foo() {
  asm("push %rax\n"
      ".code32\n");
}

we used to get this: (note that the line 4 in t.c isn't helpful)

t.c:4:7: error: warning: ignoring directive for now
  asm("push %rax\n"
      ^
<inline asm>:2:1: note: instantiated into assembly here
.code32
^

now we get:

t.c:5:8: error: warning: ignoring directive for now
      ".code32\n"
       ^
<inline asm>:2:1: note: instantiated into assembly here
.code32
^

Note that we're pointing to line 5 properly now.  This implements
rdar://7839391 - inline asm errors should point to the right line in the asm
and makes the error message in PR8595 much less confusing.

llvm-svn: 119489

SrcMgrDiagHandler, we can improve clang diagnostics for inline asm:
instead of reporting them on a source line of the original line,
we can report it on the correct line wherever the string literal came
from. For something like this:

void foo() {
  asm("push %rax\n"
      ".code32\n");
}

we used to get this: (note that the line in t.c isn't helpful)

t.c:4:7: error: warning: ignoring directive for now
  asm("push %rax\n"
      ^
<inline asm>:2:1: note: instantiated into assembly here
.code32
^

now we get:

t.c:5:8: error: warning: ignoring directive for now
      ".code32\n"
       ^
<inline asm>:2:1: note: instantiated into assembly here
.code32
^

Note that we're pointing to line 5 properly now.

llvm-svn: 119488

llvm-svn: 119487

cookie argument to the SourceMgr diagnostic stuff.  This cleanly separates
LLVMContext's inlineasm handler from the sourcemgr error handling 
definition, increasing type safety and cleaning things up.

llvm-svn: 119486

llvm-svn: 119485

llvm-svn: 119484

the cookie argument to setDiagHandler

llvm-svn: 119483

llvm-svn: 119482