MS-ABI: Mangle empty template parameter packs correctly

Tested for compatibility with VS2013.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210198 91177308-0d34-0410-b5e6-96231b3b80d8
Update for llvm api change.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210204 91177308-0d34-0410-b5e6-96231b3b80d8
This cast is not necessary any more (llvm api change).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210206 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor and generalize GetAddrOfConstantString and GetAddrOfConstantStringFromLiteral.

Share mode code between these functions and re-structure them in a way
which shows how similar they actually are. The latter function works well
with literals of multi-byte chars and does a GlobalVariable name mangling
(if global strings are non-writable).

No functionality change.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210212 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the overload of GetAddrOfConstantString method

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210214 91177308-0d34-0410-b5e6-96231b3b80d8
Don't dynamically initialize dllimport vars (PR19933)

They should be initialized when they're exported.

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

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210219 91177308-0d34-0410-b5e6-96231b3b80d8
[ubsan] Don't add a --dynamic-list for ubsan symbols when building a shared
library. That results in the linker resolving all references to weak symbols in
the DSO to the definition from within that DSO. Ironically, this rarely causes
observable problems, except that it causes ubsan's own dynamic type check to
spuriously fail (because we fail to properly merge type_info object names).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210220 91177308-0d34-0410-b5e6-96231b3b80d8
Flush C stdio streams upon process termination

Due to what can only be described as a CRT bug, stdout and amazingly
even stderr are not always flushed upon process termination, especially
when the system is under high threading pressure.  I have found two
repros for this:

1) In lib\Support\Threading.cpp, change sys::Mutex to an
std::recursive_mutex and run check-clang.  Usually between 30 and 40
tests will fail.

2) Add OutputDebugStrings in code that runs during static initialization
and static shutdown.  This will sometimes generate similar failures.

After a substantial amount of troubleshooting and debugging, I found
that I could reproduce this from the command line without running
check-clang.  Simply make the mutex change described in #1, then
manually run the following command many times by running it once, then
pressing Up -> Enter very quickly:

D:\src\llvm\build\vs2013\Debug\bin\c-index-test.EXE -cursor-at=D:\src\llvm\tools\clang\test\Index\targeted-preamble.h:2:15 D:\src\llvm\tools\clang\test\Index\targeted-cursor.c -include D:\src\llvm\build\vs2013\tools\clang\test\Index\Output\targeted-cursor.c.tmp.h -Xclang -error-on-deserialized-decl=NestedVar1      -Xclang -error-on-deserialized-decl=TopVar    | D:\src\llvm\build\vs2013\Debug\bin\FileCheck.EXE D:\src\llvm\tools\clang\test\Index\targeted-cursor.c -check-prefix=PREAMBLE-CURSOR1

Sporadically they will fail, and attaching a debugger to a failed
instance indicates that stdin of FileCheck.exe is empty.

Note that due to the repro in #2, we can rule out a bug in the STL's
mutex implementation, and instead conclude that this is a real flake in
the windows test harness.

Test Plan:
Without patch: Ran check-clang 10 times and saw over 30 Unexpected failures on every run.
With patch: Ran check-clang 10 times and saw 0 unexpected failures across all runs.

Reviewers: rnk

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

Patch by Zachary Turner!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210225 91177308-0d34-0410-b5e6-96231b3b80d8
Bugfix: don't assert if someone manages to declare an operator new/delete template before the builtin operator new/delete.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210230 91177308-0d34-0410-b5e6-96231b3b80d8
Changing this line of code back to the way it was before Alp's config.h clean up changes.
I've already spoken to Alp and he signed off on making this one change, so that our buildbots
go green in the short term.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210238 91177308-0d34-0410-b5e6-96231b3b80d8
XCore target: Fix 'typestring' binding qualifier to the array and not the type

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210250 91177308-0d34-0410-b5e6-96231b3b80d8
Fix driver warning about -shared-libasan on Android.

Asan runtime library is always shared on Android, and -shared-libasan is no-op.
Suppress the unused argument warning.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210252 91177308-0d34-0410-b5e6-96231b3b80d8
Fix driver warning about -pthread on Android.

-pthread is no-op on Android. Suppress the unused argument warning.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210253 91177308-0d34-0410-b5e6-96231b3b80d8
Fix equalsNode() to accept pointers to derived types.

Summary:
Move the 'const' in the AST_*MATCHER_P* macros to the right of ParamType to
avoiad applying the constness on the wrong level when ParamType is a pointer.
Change equalsNode() to explicitly accept 'const Decl*' or 'const Stmt*'.

Reviewers: klimek

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210269 91177308-0d34-0410-b5e6-96231b3b80d8
[mips] Add macros _MIPS_ISA and __mips_isa_rev (same expansion as defined by GCC).

Summary: The Linux Kernel is one example of a piece of software that relies on them.

Reviewers: atanasyan

Reviewed By: atanasyan

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210270 91177308-0d34-0410-b5e6-96231b3b80d8
Add pointer types to global named register

This patch adds support for pointer types in global named registers variables.
It'll be lowered as a pair of read/write_register and inttoptr/ptrtoint calls.
Also adds some early checks on types on SemaDecl to avoid the assert.

Tests changed accordingly. (PR19837)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210274 91177308-0d34-0410-b5e6-96231b3b80d8
Fix bot for named register test

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210275 91177308-0d34-0410-b5e6-96231b3b80d8
Add hasLocalStorage/hasGlobalStorage matchers.

Summary:
Add hasLocalStorage/hasGlobalStorage matchers for VarDecl nodes.
Update the doc. Also add them to the dynamic registry.

Reviewers: klimek

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210278 91177308-0d34-0410-b5e6-96231b3b80d8
[PPC64LE] Implement little-endian semantics for vec_perm

The PowerPC vperm (vector permute) instruction is defined
architecturally with a big-endian bias, in that the two input vectors
are assumed to be concatenated "left to right" and the elements of the
combined input vector are assumed to be numbered from "left to right"
(i.e., with element 0 referencing the high-order element).  This
definition is unnatural for little-endian code generation.

To facilitate ease of porting, the vec_perm interface is designed to
use natural element ordering, so that elements are numbered according
to little-endian design principles when code is generated for a
little-endian target.  The desired semantics can be achieved with the
vperm instruction provided that the two input vector registers are
reversed, and the permute control vector is complemented.  The
complementing is performed using an xor with a vector containing all
one bits.

Only the rightmost 5 bits of each element of the permute control
vector are relevant, so it would be possible to complement the vector
with respect to a <16xi8> vector containing all 31s.  However, when
the permute control vector is not a constant, using 255 instead has
the advantage that the vec_xor can be recognized during code
generation as a vnor instruction.  (Power8 introduces a vnand
instruction which could alternatively be generated.)

The correctness of this code is tested by the new perm.c test added in
a previous patch.  I plan to later make the existing ppc32 Altivec
compile-time tests work for ppc64 and ppc64le as well.


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