Summary:
Split line comments that exceed column limit + fixed leading whitespace
handling when splitting block comments.

Reviewers: djasper, klimek

Reviewed By: djasper

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D577

llvm-svn: 178133

llvm-svn: 178132

llvm-svn: 178131

Improve performance of LinkModules when linking with modules with large numbers of functions which link lazily. Instead of creating and destroying function prototypes irrespective of if they are used, only create them if they are used.

llvm-svn: 178130

llvm-svn: 178129

llvm-svn: 178128

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178127

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178126

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 178125

The R0 register can now be allocated because instructions
that cannot use R0 as a GPR have been appropriately marked.

llvm-svn: 178123

llvm-svn: 178122

The register parameter in these instructions becomes the base register in an
r+i ld instruction (and, thus, cannot be r0).

This is not yet testable because we don't yet allocate r0 (and even then any
test would be very fragile).

llvm-svn: 178121

llvm-svn: 178120

Either operand of these pseudo instructions can be transformed into the first
operand of an isel instruction (and this operand cannot be r0).

This is not yet testable because we don't yet allocate r0 (and even when we do,
any test would be very fragile).

llvm-svn: 178119

Like the addi/addis instructions themselves, these pseudo instructions also
cannot have r0 as their register parameter (because it will be interpreted as
the value 0).

This is not yet testable because we don't yet allocate r0 (and even when we do,
any regression test would be very fragile because it would depend on the
register allocator heuristics).

llvm-svn: 178118

[lib/Headers] Break the module import cycle between _Builtin_intrinsics.sse and _Builtin_intrinsics.sse2

Module "sse" implicitly exports module "sse2".
This is bad because we also have module "sse2" export module "sse" (as intended) so we end up with a cycle
in the module import graph:
1. sse2 -> (also imports) sse
2. sse -> (also imports) sse2

To eliminate the cycle remove 2.; importing module "sse2" will also import module "sse", but just importing
module "sse" will not also import module "sse2".

rdar://13240552

llvm-svn: 178117

bootstrap with libc++.

llvm-svn: 178116

LLDB to crash.

<rdar://problem/13497915>

llvm-svn: 178115

Some implementation detail in the forgotten past required the link
register to be placed in the GPRC and G8RC register classes.  This is
just wrong on the face of it, and causes several extra intersection
register classes to be generated.  I found this was having evil
effects on instruction scheduling, by causing the wrong register class
to be consulted for register pressure decisions.

No code generation changes are expected, other than some minor changes
in instruction order.  Seven tests in the test bucket required minor
tweaks to adjust to the new normal.

llvm-svn: 178114

Don't use a "uintptr_t" for the metadata key, use a "void *".  This removes all of the casts that were being used and cleans the code up a bit. Also added the ability to dump the metadata.

llvm-svn: 178113

llvm-svn: 178112

Patch by me and Ryan Molden.

llvm-svn: 178111

This makes it identical with the system definition.

llvm-svn: 178110

the system macro uses a not identical definition compared to a macro from the clang headers.

For example (these come from different modules):
   \#define LONG_MAX __LONG_MAX__ (clang's limits.h)
   \#define LONG_MAX 0x7fffffffffffffffL (system's limits.h)
in which case don't mark them ambiguous to avoid the "ambiguous macro expansion" warning.

llvm-svn: 178109

It's not used anymore.

llvm-svn: 178108

llvm-svn: 178107

It's not used anymore.

llvm-svn: 178106

Also update "test/Modules/macros.c" to test modified semantics:
-When there is an ambiguous macro, expand using the latest introduced version, not the first one.
-#undefs in submodules cause the macro to not be exported by that submodule, it doesn't cause
 undefining of macros in the translation unit that imported that submodule.
 This reduces macro namespace interference across modules.

llvm-svn: 178105

Revised to use MemoryBuffer. Removed redundant llvm:: qualifiers.  Removed unnecessary c_str() calls.  Reformatted with clang-format.

llvm-svn: 178104

uninstantiated exception specification when a special member within a class
template is both defaulted and given an exception specification on its first
declaration.

llvm-svn: 178103

backend output; there's no need to report a fatal error.  This reverts r178042.
Part of rdar://13295753 and rdar://13401547

llvm-svn: 178102

The test was removed since I had not turned off the test during release
builds. This fails since ARC annotations support  is conditionally
compiled out during release builds. I added the proper requires header
to assuage this issue.

llvm-svn: 178101

This accounts for the addition of another field to DIScopes that will be used
to store a list of DIImportedModules in the future.

llvm-svn: 178100

This is just the basic groundwork for supporting DW_TAG_imported_module but I
wanted to commit this before pushing support further into Clang or LLVM so that
this rather churny change is isolated from the rest of the work. The major
churn here is obviously adding another field (within the common DIScope prefix)
to all DIScopes (files, classes, namespaces, lexical scopes, etc). This should
be the last big churny change needed for DW_TAG_imported_module/using directive
support/PR14606.

llvm-svn: 178099

declarations at any point. Patch by Alexander Zinenko, and
report by Richard Smith.

llvm-svn: 178098

Previously all unimplemented methods for a class were grouped under
a single warning, with all the unimplemented methods mentioned
as notes.  Based on feedback from users, most users would like
a separate warning for each method, with a note pointing back to
the original method declaration.

Implements <rdar://problem/13350414>

llvm-svn: 178097

As Bill Schmidt pointed out to me, only on Darwin do we need to spill/restore
VRSAVE in the SjLj code. For non-Darwin, don't spill/restore VRSAVE (and I've
added some asserts to make sure that we're not).

As it turns out, we're not currently handling the Darwin case correctly (I've
added a FIXME in the test case). I've tried adding various implied register
definitions/uses to force the spill without success, so I'll need to address
this later.

llvm-svn: 178096

<rdar://problem/13278115> Improve diagnostic when failing to bind an rvalue reference to an lvalue of compatible type.

llvm-svn: 178095

Jordan pointed out that my previously committed test was bogus.

llvm-svn: 178094

Register the nil tracking visitors with the region and refactor trackNullOrUndefValue a bit.

Also adds the cast and paren stripping before checking if the value is an OpaqueValueExpr
or ExprWithCleanups.

llvm-svn: 178093