U    include/llvm/LLVMContext.h
U    lib/VMCore/LLVMContext.cpp
U    lib/AsmParser/LLParser.cpp
U    lib/AsmParser/LLParser.h

Temporarily reverting r74648. It was causing massive failures in release mode.

llvm-svn: 74653

No functionality change.

llvm-svn: 74652

by distinguishing between substitution that occurs for template
argument deduction vs. explicitly-specifiad template arguments. This
is used both to improve diagnostics and to make sure we only provide
SFINAE in those cases where SFINAE should apply.

In addition, deal with the sticky issue where SFINAE only considers
substitution of template arguments into the *type* of a function
template; we need to issue hard errors beyond this point, as
test/SemaTemplate/operator-template.cpp illustrates.

llvm-svn: 74651

llvm-svn: 74650

llvm-svn: 74649

llvm-svn: 74648

llvm-svn: 74647

llvm-svn: 74646

llvm-svn: 74645

llvm-svn: 74644

llvm-svn: 74642

addressing mode is encoded in the second operand, not the third.

llvm-svn: 74641

llvm-svn: 74640

No change in functionality.

llvm-svn: 74639

llvm-svn: 74638

 - Refactored slightly to make control flow more obvious.

llvm-svn: 74637

llvm-svn: 74636

 - The Compilation is just a helper class, it shouldn't have that amount of
   logic in it.

 - No functionality change.

llvm-svn: 74634

llvm-svn: 74633

llvm-svn: 74632

Also has fix for bugzilla-4469.

llvm-svn: 74631

!0 = constant metadata !{i32 21, i32 22}
@llvm.blah = constant metadata !{i32 1000, i16 200, metadata !0}

llvm-svn: 74630

 - Not all tools give good error messages, and sometimes the tool can fail w/o
   any error (for example, when signalled).

 - We suppress this message when the failing command is the compiler and it
   failed normally (exit code == 1), under the assumption that it gave a good
   diagnostic.

For example, for a linker failure we now get:
--
ddunbar@lordcrumb:tmp$ clang a.c b.c
ld: duplicate symbol _x in /var/folders/cl/clrOX6SaG+moCeRKEI4PtU+++TI/-Tmp-/cc-bXYITq.o and /var/folders/cl/clrOX6SaG+moCeRKEI4PtU+++TI/-Tmp-/cc-6uK4jD.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
--

For a compiler crash we get:
--
ddunbar@lordcrumb:tmp$ clang t.i
Assertion failed: (CGT.getTargetData().getTypeAllocSizeInBits(STy) == RL.getSize()), function layoutStructFields, file CodeGenTypes.cpp, line 573.
0   clang-cc          0x0000000100f1f1f1 PrintStackTrace(void*) + 38
... stack trace and virtual stack trace follow ...
clang: error: compiler command failed due to signal 6 (use -v to see invocation)
--

But for a regular compilation failure we get the usual:
--
ddunbar@lordcrumb:tmp$ clang c.c
c.c:1:6: error: invalid token after top level declarator
int x
     ^
1 diagnostic generated.
--

 - No test case, not amenable to non-executable testing. :/

 - <rdar://problem/6945613>

llvm-svn: 74629

llvm-svn: 74628

Command to be generated, to support more advanced diagnostics.
 - No functionality change.

llvm-svn: 74627

llvm-svn: 74626

llvm-svn: 74625

bytes and not bytes.

llvm-svn: 74624

llvm-svn: 74623

llvm-svn: 74622

Windows variant, strerror_s, but I couldn't test that.

I'll update configure and config.h.in in a subsequent patch.

llvm-svn: 74621

llvm-svn: 74620

I give up on trying to use reader/writer locks for recursive type refinement.  Use a recursive mutex instead, which will (in theory) generate more contention, but is really
a much more natural fit for what's going on during recursive type refinement.

llvm-svn: 74618

llvm-svn: 74617

llvm-svn: 74615

Add a pointer to the owning LLVMContext to Module.  This requires threading LLVMContext through a lot
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.

Patches for Clang and LLVM-GCC to follow.

llvm-svn: 74614

PR4482.

llvm-svn: 74613

llvm-svn: 74612

Executables will be at InstallDir/bin directory. Std header files will be at InstallDir/include, libs will be at InstallDir/lib. Define hooks for these and use them in the options for various tools.

llvm-svn: 74611

variable is present.

llvm-svn: 74610