directly manipulates the weights inside of the BranchProbabilityInfo
that is passed in.

llvm-svn: 142163

llvm-svn: 142162

llvm-svn: 142160

end result. Use this split to propagate state information and diagnostics
through more of constant expression evaluation.

llvm-svn: 142159

llvm-svn: 142158

llvm-svn: 142157

llvm-svn: 142155

llvm-svn: 142154

llvm-svn: 142153

Changed tests which assumed that vectors are legalized by widening them.

llvm-svn: 142152

llvm-svn: 142151

on the memcpy call will pull up other unrelated stuff. Fixes PR11142.

llvm-svn: 142150

The decision was to pack the bits. Currently no codegen supports this.
Currently, all of the bits in the vector are saved into the same address
in memory.

llvm-svn: 142149

llvm-svn: 142148

This also applies to C99-style aggregate literals, should they be used in C++11, since they are effectively identical to constructor call list-initialization syntax.

llvm-svn: 142147

In the verify-only pass, check that items that don't have an initializer in an init list can be value-initialized, at least when designated initializers are not involved. No test case yet, since early failures cannot be distinguished from late failures until overload resolution works.

llvm-svn: 142146

llvm-svn: 142145

llvm-svn: 142144

Drop the Diagnose parameter from Sema::PerformImplicitConversion again and instead use TryImplicitConversion in CheckSingleAssignmentConstraints when that function is in no-diagnostics mode.

llvm-svn: 142143

Make a C-style cast a const-cast, to suppress a GCC warning. I should fix the underlying issue eventually, but this interface will probably change anyway.

llvm-svn: 142142

llvm-svn: 142141

While at it, merge some format strings.

llvm-svn: 142140

llvm-svn: 142139

llvm-svn: 142138

<stdin>:1:12: error: register %rax is only available in 64-bit mode
   incl    %rax
           ^~~~

llvm-svn: 142137

llvm-svn: 142136

X86AsmParser: Synthesize EndLoc for tokens out of StartLoc + Length and print ranges for invalid operands.

<stdin>:1:4: error: invalid instruction mnemonic 'abc'
   abc incl    %edi
   ^~~

llvm-svn: 142135

llvm-svn: 142134

'libdir' mean the actual library directory, not the GCC subdirectory of
the library directory. That was just a confusing pattern. Instead,
supply proper GCC subdirectories when scanning for various triple-based
subdirectories with a GCC installation in them. This also makes it much
more obvious how multiarch installations, which have a triple-based
prefix as well as suffix work.

Also clean up our handling of these triple-prefixed trees by using them
in both a multiarch pattern and a non-multiarch pattern whenever they
exist.

Note that this *does not* match what GCC does on Debian, the only truly
multiarch installation I've been able to get installed and test on. GCC
appears to have a bug, and ends up searching paths like
'/lib/../../lib32' which makes no sense what-so-ever. Instead, I've
tried to encode the rational logic that seems clearly intended by GCC's
pattern. GCC ends up with patterns like:

  /lib/../../lib32
  /usr/lib/../../lib32
  /usr/lib/x86_64-linux-gnu/../..lib32

Only the last one makes any sense having a '/../..' in it, so in Clang,
that's the only one which gets a '/../..' in it.

I *think* this will fix Debian multiarch links. I'm committing without
baking this logic into our test suite so I can test on a few different
systems. If all goes well (and no one screams) I'll check in some more
comprehensive tests for multiarch behavior tomorrow.

llvm-svn: 142133

This reenables proper inline asm diagnostics in clang

llvm-svn: 142132

t.c:2:7: error: invalid operand for instruction
  asm("movl 0(%rax), 0(%edx)");
      ^
<inline asm>:1:16: note: instantiated into assembly here
        movl 0(%rax), 0(%edx)
                      ^~~~~~~
1 error generated.

llvm-svn: 142131

no pattern.

llvm-svn: 142130

llvm-svn: 142129

function. No functionality changed.

llvm-svn: 142128

formatting as any other diagnostic, they will be properly line wrapped and
otherwise pretty printed. Let's take advantage of that and the new factoring to
add some helpful information to them (much like template backtrace notes and
other notes): the name of the macro whose expansion is being noted. This makes
a world of difference if caret diagnostics are disabled, making the expansion
notes actually useful in this case. It also helps ensure that in edge cases the
information the user needs is present. Consider:

% nl -ba t5.cc
     1  #define M(x, y, z) \
     2    y
     3
     4  M(
     5    1,
     6    2,
     7    3);

We now produce:
% ./bin/clang -fsyntax-only t5.cc
t5.cc:6:3: error: expected unqualified-id
  2,
  ^
t5.cc:2:3: note: expanded from macro: M
  y
  ^
1 error generated.

Without the added information in the note, the name of the macro being expanded
would never be shown.

This also deletes a FIXME to use the diagnostic formatting. It's not yet clear
to me that we *can* do this reasonably, and the production of this message was
my primary goal here anyways.

I'd love any comments or suggestions on improving these notes, their wording,
etc. Currently, I need to make them provide more helpful information in the
presence of a token-pasting buffer, and I'm pondering adding something along
the lines of "expanded from argument N of macro: ...".

llvm-svn: 142127

llvm-svn: 142125

LangImpl6.html (it needed to defined the 'binary :' operator).
PR9052

llvm-svn: 142123

llvm-svn: 142122

this long quest: actually use the note printing machinery for each macro
expansion note rather than a hacky version of it. This will colorize and
format the notes the same as any other. There is still some stuff to fix
here, but it's one step closer.

No test case changes because currently we don't do anything differently
that I can FileCheck for -- I don't really want to try matching the
color escape codes... Suggestions for how to test this are welcome. =]

llvm-svn: 142121

standing deficiency: we were providing no macro backtrace information
whenever caret diagnostics were turned off. This sinks the logic for
suppressing the code snippet and caret to the code that actually prints
tho code snippet and caret. Along the way, clean up the naming of
functions, remove some now fixed FIXMEs, and generally improve the
wording and logic of this process.

Add a test case exerecising this functionality. It is notable that the
resulting messages are extremely low quality. I'm working on a follow-up
patch that should address this and have left a FIXME in the test case.

llvm-svn: 142120