llvm-svn: 110784

llvm-svn: 110776

 - We don't recognize double or NEON register names yet -- we don't have the
   infrastructure to generate the right clobbers for them.

llvm-svn: 110775

llvm-svn: 110774

implicit conversion sequences. In particular, model the "standard
conversion" from a class to its own type (or a base type) directly as
a standard conversion in the normal path *without* trying to determine
if there is a valid copy constructor. This appears to match the intent
of C++ [over.best.ics]p6 and more closely matches GCC and EDG.

As part of this, model non-lvalue reference initialization via
user-defined conversion in overloading the same way we handle it in
InitializationSequence, separating the "general user-defined
conversion" and "conversion to compatible class type" cases.

The churn in the overload-call-copycon.cpp test case is because the
test case was originally wrong; it assumed that we should do more
checking for copy constructors that we actually should, which affected
overload resolution.

Fixes PR7055. Bootstrapped okay.

llvm-svn: 110773

Remove 256-bit cast built-ins and make the AVX intrinsic call llvm __builtin_shufflevector with the appropriate arguments

llvm-svn: 110771

llvm-svn: 110770

Remove 256-bit unpack built-ins and make the AVX intrinsic call llvm __builtin_shufflevector with the appropriate arguments

llvm-svn: 110768

Remove 256-bit shuffle built-ins and make the AVX intrinsic call llvm __builtin_shufflevector with the appropriate arguments

llvm-svn: 110766

llvm-svn: 110764

where we weren't accounting for the possibility that a @finally block might
have internal cleanups and therefore might write to the cleanup destination slot.

Fixes <rdar://problem/8293901>.

llvm-svn: 110760

Have GRCoreEngine record the blocks where analysis was aborted because we visited a block too many times along a given path.  This is to support the unreachable code analysis.

llvm-svn: 110755

Add test case for <rdar://problem/8288645>.  While this is fixed in trunk, we previously were getting the following assertion failure not too long ago:

Assertion failed: (getContainingDC(DC) == CurContext && "The next DeclContext should be lexically contained in the current one.")

llvm-svn: 110740

Something's wrong with this test on other platforms.  I'll probably need to simplify it later.  For now revert.

llvm-svn: 110738

llvm-svn: 110729

llvm-svn: 110716

llvm-svn: 110713

llvm-svn: 110709

llvm-svn: 110708

llvm-svn: 110706

the variable is fully initialized.

llvm-svn: 110704

(radar 8127244).

llvm-svn: 110702

llvm-svn: 110697

type receiver (pr7861).

llvm-svn: 110696

llvm-svn: 110695

Simplify code and add comments, in code that generate debug info for constant integer globals, based on Chris's feedback.

llvm-svn: 110694

cases we care about.
 - This is eventually going to be unified outside the host specific code.

llvm-svn: 110693

provided by __builtin_types_compatible_p and __builtin_va_arg
expressions, now that Abramo has added proper type-source information
to those expressions.

llvm-svn: 110681

transforming TypeSourceInfos already gives us proper (and better)
source-location information.

llvm-svn: 110678

llvm-svn: 110677

llvm-svn: 110666

llvm-svn: 110663

llvm-svn: 110660

fix an issue compiling <windows.h>.

llvm-svn: 110651

llvm-svn: 110646

llvm-svn: 110644

There is no need to pubish file static variable's name. Do not rely on this code gen bug to check whether debug info is generated for such variables or not.

llvm-svn: 110640

llvm-svn: 110635

llvm-svn: 110629

(radar 8127244).

llvm-svn: 110622