Do not predefine __EXCEPTIONS in clang-cl (PR19977)

Patch by Ehsan Akhgari! (Test tweak by me.)

Differential Revision: http://reviews.llvm.org/D4065

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210582 91177308-0d34-0410-b5e6-96231b3b80d8
Remove a redundant conditional when caching typo failures.

No functionality change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210583 91177308-0d34-0410-b5e6-96231b3b80d8
Fix crash with x86_64-pc-win32-macho target. <rdar://problem/17235840>

The changes in r204978 broke win32-macho targets. There were checks added for
MSVC and Itanium environments as special cases, and win32-macho needs to be
treated the same way.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210584 91177308-0d34-0410-b5e6-96231b3b80d8
PR19992: alignof is permitted on an array of unknown bound.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210585 91177308-0d34-0410-b5e6-96231b3b80d8
Try to fix clang-hexagon-elf failure by requiring x86 support for this test.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210586 91177308-0d34-0410-b5e6-96231b3b80d8
*Really* fix DOS newlines introduced in r210330

r210369 didn't quite catch all of them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210593 91177308-0d34-0410-b5e6-96231b3b80d8
Clang changes to support LLVM removal of runtime multithreading
support (llvm revision r210600).

Reviewers: rnk

Differential Revision: http://reviews.llvm.org/D4077

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210601 91177308-0d34-0410-b5e6-96231b3b80d8
Revert "Clang changes to support LLVM removal of runtime multithreading"

This reverts r210601.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210604 91177308-0d34-0410-b5e6-96231b3b80d8
Recover from missing typenames on template args for MSVC compatibility

While matching a non-type template argument against a known template
type parameter we now modify the AST's TemplateArgumentLoc to assume the
user wrote typename.  Under -fms-compatibility, we downgrade our
diagnostic from an error to an extwarn.

Reviewed by: rsmith

Differential Revision: http://reviews.llvm.org/D4049

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210607 91177308-0d34-0410-b5e6-96231b3b80d8
Related to PR19992: when the GNU alignof-expression extension is applied to an
expression of array-of-unknown-bound type, don't try to complete the array
bound, and return the alignment of the element type rather than 1.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210608 91177308-0d34-0410-b5e6-96231b3b80d8
Teach __alignof__ to look through arrays before performing the
preferred-alignment transformations. Corrects alignof(T[]) to return
alignof(T) in all cases, as required by relevant standards.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210609 91177308-0d34-0410-b5e6-96231b3b80d8
Allow lookup into dependent bases in more places under -fms-compatibility

We currently allow unqualified lookup for instance methods but not
static methods because we can't recover with a semantic 'this->'
insertion.

ATL headers have static methods that do unqualified lookup into
dependent base classes.  The pattern looks like:

  template <typename T> struct Foo : T {
    static int *getBarFromT() { return Bar; }
  };

Now we recover as if the user had written:

  template <typename T> struct Foo : T {
    static int *getBarFromT() { return Foo::Bar; }
  };

... which will eventually look up Bar in T at instantiation time.

Now we emit a diagnostic in both cases, and delay lookup in other
contexts where 'this' is available and refers to a class with dependent
bases.

Reviewed by: rsmith

Differential Revision: http://reviews.llvm.org/D4079

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210611 91177308-0d34-0410-b5e6-96231b3b80d8
PR19996: don't crash if -Wuninitialized sees a c++1y lambda init-capture.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210615 91177308-0d34-0410-b5e6-96231b3b80d8
PR19993: don't assert/crash if a static data member is initialized by '= delete;'.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210617 91177308-0d34-0410-b5e6-96231b3b80d8
Ensure test/Misc/win32-macho.c doesn't try to write to the source tree

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210618 91177308-0d34-0410-b5e6-96231b3b80d8
[AArch64] Add default features for CPUs on AArch64 target.

For ARM target, we can use CRYPTO and CRC features if we select
cortex-a57 by '-mcpu', but for AArch64 target, it doesn't work
unless adding with '-mfpu=crypto-neon-fp-armv8'. To keep consistency
between front-end and back-end and get end-users more easier to use,
we'd better add default feature for CPUs on AArch64 target as well.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210625 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen: Correct linkage of thread_local for OS X

The backing store of thread local variables is internal for OS X and all
accesses must go through the thread wrapper.

However, individual TUs may have inlined through the thread wrapper.
To fix this, give the thread wrapper functions WeakAnyLinkage.  This
prevents them from getting inlined into call-sites.

This fixes PR19989.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210632 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Mangle null pointer-to-member-functions compatibly

Summary:
Previously, we would mangle nullptr pointer-to-member-functions in class
templates with a mangling we invented because contemporary versions of
MSVC would crash when trying to compile such code.

However, VS "14" can successfully compile these sorts of template
instantiations.  This commit updates our mangling to be compatible with
theirs.

Reviewers: rnk

Reviewed By: rnk

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D4059

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210637 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Only class templates get complex nullptr pointer-to-member-functions

r210637 regressed CodeGenCXX/mangle-ms-templates-memptrs.cpp because it
did not believe that there is a distinction between class templates and
function templates.

Sadly, there is.  Function templates should behave in a compatible
manner with MSVC.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210642 91177308-0d34-0410-b5e6-96231b3b80d8
clang-format: Fix pointer/reference detection after decltype.

Before:
  [](const decltype(*a) & value) {}

After:
  [](const decltype(*a)& value) {}

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210643 91177308-0d34-0410-b5e6-96231b3b80d8