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

backtrace behavior.

llvm-svn: 142119

the important code in this test to make the test more stable. Now adding
further tests won't shift the line numbers occuring in the diagnostic
output.

llvm-svn: 142118

Add X86 INVPCID instruction. Add 32/64-bit predicates to INVEPT, INVVPID, VMREAD, and VMWRITE to remove hack from X86RecognizableInstr.

llvm-svn: 142117

tests to it to cover more of the macro bactrace functionality.

llvm-svn: 142116

llvm-svn: 142113

llvm-svn: 142112

These missing flags show up as errors when running -verify-coalescing on
test-suite.

llvm-svn: 142111

llvm-svn: 142110

llvm-svn: 142109

llvm-svn: 142108

string, pass it around as an enum.

llvm-svn: 142107

the X86 asmparser to produce ranges in the one case that was annoying me, for example:

test.s:10:15: error: invalid operand for instruction
movl 0(%rax), 0(%edx)
              ^~~~~~~

It should be straight-forward to enhance filecheck, tblgen, and/or the .ll parser to use 
ranges where appropriate if someone is interested.

llvm-svn: 142106

Add X86 BEXTR instruction. This instruction uses VEX.vvvv to encode Operand 3 instead of Operand 2 so needs special casing in the disassembler and code emitter. Ultimately, should pass this information from tablegen

llvm-svn: 142105

the SourceManager doesn't change, and the source files don't change.
This greatly simplifies the interfaces and interactions. The lifetime of
the TextDiagnostic object forms the 'session' over which we attempt to
condense and deduplicate information in diagnostics.

llvm-svn: 142104

CMake: Introduce LLVM_CLANG_SOURCE_DIR, "tools/clang" by default. Clang will not be built if LLVM_CLANG_SOURCE_DIR="" or ${LLVM_CLANG_SOURCE_DIR}/CMakeLists.txt is not found.

llvm-svn: 142103

autoconf: Introduce --with-clang-srcdir, to build out-of-tree clang as tools/clang on tools/Makefile.

llvm-svn: 142102

llvm-svn: 142101

test/Makefile: Inspect $(PROJ_OBJ_ROOT)/tools/clang/Makefile instead of $(PROJ_SRC_ROOT)/tools/clang for "check-all".

llvm-svn: 142100

llvm-svn: 142098

llvm-svn: 142097

Add X86 feature detection support for BMI instructions. Added new cpuid function for accessing leafs with sub leafs specified in ECX. Also added code to keep track of the max cpuid level supported in both basic and extended leaves and qualified the existing cpuid calls and the new call to leaf 7.

llvm-svn: 142089