[SystemZ] Add test case to verify default use of integrated assembler



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219679 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Don't leak location information from one function into the prologue of the next function.

CodeGenFunction objects aren't really designed to be reused for more
than one function, and doing so can leak debug info location information
from one function into the prologue of the next.

Add an assertion in to catch reuses of CodeGenFunction, which
surprisingly only caught the ObjC atomic getter/setter cases. Fix those
and add a test to demonstrate the issue.

The test is a bit slim, because we're just testing for the absence of a
debug location on the prologue instructions, which by itself probably
wouldn't be the end of the world - but the particular debug location
that was ending up there was for the previous function's last
instruction. This produced debug info for another function within this
function, which is something I'm trying to remove all cases of as its a
substantial source of bugs, especially around inlining (see r219215).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219690 91177308-0d34-0410-b5e6-96231b3b80d8
[SystemZ] Address review comments for r219679


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219691 91177308-0d34-0410-b5e6-96231b3b80d8
Formatting for prior commit

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219692 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen: correct mangling for blocks

This addresses a regression introduced with SVN r219393.  A block may be
contained within another block.  In such a scenario, we would end up within a
BlockDecl, which is not a NamedDecl (as the names are synthesised).  The cast to
a NamedDecl of the DeclContext would then assert as the types are unrelated.

Restore the mangling behaviour to that prior to SVN r219393.  If the current
block is contained within a BlockDecl, walk up to the parent DeclContext,
recursively, until we have a non-BlockDecl.  This is expected to be a NamedDecl.
Add in a couple of asserts to ensure that the assumption that we only encounter
a block within a NamedDecl or a BlockDecl.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219696 91177308-0d34-0410-b5e6-96231b3b80d8
CodeGen: correct block mangling in ObjC

Mangling for blocks defined within blocks in an ObjectiveC context were also
broken by SVN r219393.  Because the code in mangleName assumed that the code was
either C or C++, we would trigger assertions when trying to mangle the inner
blocks in an ObjectiveC context.

Add a test and use the ObjectiveC specific mangling when dealing with an
ObjectiveC method declaration.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219697 91177308-0d34-0410-b5e6-96231b3b80d8
Patch to warn on interger overflow in presence of
implicit casts. Reviewed by Reid Kleckner.
rdar://18405357


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219712 91177308-0d34-0410-b5e6-96231b3b80d8
Factor code into CXXRecordDecl::getTemplateInstantiationPattern() helper

This moves some code from SemaType.cpp's hasVisibleDefinition() into
DeclCXX.cpp so that it can be used elsewhere. I found one other instance
of code trying to do the same thing, there are probably more. Search for
getInstantiatedFrom() to try to find more.

No functionality change.

Reviewed By: rsmith

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219714 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: set preferred aggregate alignment to 32 universally.

Before, ARM and Thumb mode code had different preferred alignments, which could
lead to some rather unexpected results. There's justification for reducing it
from the default 64-bits (wasted space), but I don't think there is for going
below 32-bits.

There's no actual ABI change here, just to reassure people.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219720 91177308-0d34-0410-b5e6-96231b3b80d8
Be smarter when parsing variable declarations with unknown types.

Specifically, avoid typo-correcting the variable name into a type before
typo-correcting the actual type name in the declaration. Doing so
results in a very unpleasant cascade of errors, with the typo correction
of the actual type name being buried in the middle.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219732 91177308-0d34-0410-b5e6-96231b3b80d8
ARM: remove ARM/Thumb distinction for preferred alignment.

Thumb1 has legitimate reasons for preferring 32-bit alignment of types
i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be
a multiple of 4. However, this is a trade-off betweem code size and RAM usage;
the DataLayout string is not the best place to represent it even if desired.

So this patch removes the extra Thumb requirements, hopefully making ARM and
Thumb completely compatible in this respect.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219735 91177308-0d34-0410-b5e6-96231b3b80d8
DebugInfo: Lazily built static member variable declarations should use the canonical declaration for line/file information.

When lazily constructing static member variable declarations (when
the vtable optimization fires and the definition of the type is omitted
(or built later, lazily), but the out of line definition of the static
member is provided and must be described in debug info) ensure we use
the canonical declaration when computing the file, line, etc for that
declaration (rather than the definition, which is also a declaration,
but not the canonical one).

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219736 91177308-0d34-0410-b5e6-96231b3b80d8
MS Compat: interpose vadefs.h to fix definitions of _crt_va_{start,end,arg} (PR21247)

Differential revision: http://reviews.llvm.org/D5784

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219740 91177308-0d34-0410-b5e6-96231b3b80d8
Sort files list in lib/Headers/CMakeLists.txt

majnemer pointed out that vadefs.h was added in the wrong place. Might
as well sort the rest too.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219743 91177308-0d34-0410-b5e6-96231b3b80d8
clang-cl: Diagnose the usage of ASAN with a debug runtime library

Summary:
AddressSanitizer currently doesn't support this configuration, and binaries
built with it will just get into an infinite loop during startup.

Test Plan: Includes an automated test.

Reviewers: samsonov

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219744 91177308-0d34-0410-b5e6-96231b3b80d8
vadefs.h: be even more conservative and only define the macros if already defined

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219745 91177308-0d34-0410-b5e6-96231b3b80d8
Frontend: Remove some unused arguments in ASTUnit (NFC)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219747 91177308-0d34-0410-b5e6-96231b3b80d8
Frontend: Don't accept null DiagnosticsEngines when building ASTUnits

The various ways to create an ASTUnit all take a refcounted pointer to
a diagnostics engine as an argument, and if it isn't pointing at
anything they initialize it. This is a pretty confusing API, and it
really makes more sense for the caller to initialize the thing since
they control the lifetime anyway.

This fixes the one caller that didn't bother initializing the pointer
and asserts that the argument is initialized.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219752 91177308-0d34-0410-b5e6-96231b3b80d8
Improvements to -Wnull-conversion

Split logic to separate checking function
Refine the macro checking
Catch nullptr->bool conversions
Add some explanatory comments


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219774 91177308-0d34-0410-b5e6-96231b3b80d8
MS ABI: Use the correct this arg when generating implicit array copy ctor

We assumed the last argument of the copy constructor was the this
pointer.  However, this is not the case under the MS ABI.

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