Keep the old function order in CodeGenModule::applyReplacements.

The original decls are created when used. The replacements are created at the
end of the TU in reverse order.

This makes the origina

Keep the old function order in CodeGenModule::applyReplacements.

The original decls are created when used. The replacements are created at the
end of the TU in reverse order.

This makes the original order far better for testing. This is particularly
important since the replacement logic could be used even when
-mconstructor-aliases is not used, but that would make many tests hard to read.

This is a fixed version of r194357 which handles replacing a destructor with
another which is an alias to a third one.

llvm-svn: 194452

show more ...

Revert "Keep the old function order in CodeGenModule::applyReplacements."

This reverts commit r194357.

Debugging a cast failure during bootstrap.

llvm-svn: 194358

Keep the old function order in CodeGenModule::applyReplacements.

The original decls are created when used. The replacements are created at the
end of the TU in reverse order.

This makes the origina

Keep the old function order in CodeGenModule::applyReplacements.

The original decls are created when used. The replacements are created at the
end of the TU in reverse order.

This makes the original order far better for testing. This is particularly
important since the replacement logic could be used even when
-mconstructor-aliases is not used, but that would make many tests hard to read.

llvm-svn: 194357

show more ...

Avoid double StringMap lookups. No functionality change.

llvm-svn: 194355

Produce direct calls instead of alias to linkonce_odr functions.

This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two i

Produce direct calls instead of alias to linkonce_odr functions.

This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two identical ones.

llvm-svn: 194095

show more ...

C++1y sized deallocation: if we have a use, but not a definition, of a sized
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable def

C++1y sized deallocation: if we have a use, but not a definition, of a sized
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable definition of the function that
forwards to the corresponding unsized deallocation.

This allows a C++ standard library implementation to provide both a sized and
an unsized deallocation function, where the unsized one does not just call the
sized one, for instance by putting both in the same object file within an
archive.

llvm-svn: 194055

show more ...

New fix for pr17535.

This is a fixed version of r193161. In order to handle

void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));

it is not

New fix for pr17535.

This is a fixed version of r193161. In order to handle

void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));

it is not enough to delay aliases to the end of the TU, we have to do two
passes over them to find if they are defined or not.

This can be implemented by producing alias as we go and just doing the second
pass at the end. This has the advantage that other parts of clang that were
expecting alias to be processed in order don't have to be changed.

This patch also handles cyclic aliases.

llvm-svn: 193188

show more ...

Revert "This patch causes clang to reject alias attributes that point to undefined names. For example, with this patch we now reject"

This reverts commit r193161.

It broke

void foo() __attribute__

Revert "This patch causes clang to reject alias attributes that point to undefined names. For example, with this patch we now reject"

This reverts commit r193161.

It broke

void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));

Looks like we have to fix pr17639 first :-(

llvm-svn: 193162

show more ...

This patch causes clang to reject alias attributes that point to undefined
names. For example, with this patch we now reject

void f1(void) __attribute__((alias("g1")));

This patch is implemented in

This patch causes clang to reject alias attributes that point to undefined
names. For example, with this patch we now reject

void f1(void) __attribute__((alias("g1")));

This patch is implemented in CodeGen. It is quiet a bit simpler and more
compatible with gcc than implementing it in Sema. The downside is that the
errors only fire during -emit-llvm.

llvm-svn: 193161

show more ...

Rename some functions for consistency.

Every other function in Redeclarable.h was using Decl instead of Declaration.

llvm-svn: 192900

Emit a .ident saying that clang produced this file.

Patch by Katya Romanova.

llvm-svn: 192832

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

An updated version of r191586 with bug fix.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

An updated version of r191586 with bug fix.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.

We should not generate a TBAA tag with null being the first field. When
a TBAA type node is null, the tag should be null too. Make sure we
don't decorate an instruction with a null TBAA tag.

Added a testing case for the bug reported by Richard with -relaxed-aliasing
and -fsanitizer=thread.

llvm-svn: 192145

show more ...

Revert r191586 and r191695. They cause crashes when building with
-relaxed-aliasing.

llvm-svn: 191725

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.

llvm-s

TBAA: use the same format for scalar TBAA and struct-path aware TBAA.

Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.

llvm-svn: 191586

show more ...

Do not emit duplicate global initializers for template static data members inside namespaces

A quirk of AST representation leads to class template static data member
definitions being visited twice

Do not emit duplicate global initializers for template static data members inside namespaces

A quirk of AST representation leads to class template static data member
definitions being visited twice during Clang IRGen resulting in
duplicate (benign) initializers.

Discovered while investigating a possibly-related debug info bug tickled
by the duplicate emission of these members & their associated debug
info.

With thanks to Richard Smith for help investigating, understanding, and
helping with the fix.

llvm-svn: 189996

show more ...

Emit uuid globals as linkonce_odr

Patch by Nico Rieck!

llvm-svn: 189860

Use pop_back_val() instead of both back() and pop_back().
No functionality change intended.

llvm-svn: 189112

PR16933: Don't try to codegen things after we've seen errors.

Refactor the underlying code a bit to remove unnecessary calls to
"hasErrorOccurred" & make them consistently at all the entry points to

PR16933: Don't try to codegen things after we've seen errors.

Refactor the underlying code a bit to remove unnecessary calls to
"hasErrorOccurred" & make them consistently at all the entry points to
the IRGen ASTConsumer.

llvm-svn: 188707

show more ...

CodeGen: __uuidof should work even with an incomplete _GUID type

Summary:
We would crash in CodeGen::CodeGenModule::EmitUuidofInitializer
because our attempt to enter CodeGen::CodeGenModule::EmitCon

CodeGen: __uuidof should work even with an incomplete _GUID type

Summary:
We would crash in CodeGen::CodeGenModule::EmitUuidofInitializer
because our attempt to enter CodeGen::CodeGenModule::EmitConstantValue
will be foiled: the type of the constant value is incomplete.

Instead, create an unnamed type with the proper layout on all platforms.
Punt the problem of wrongly defined struct _GUID types to the user.
(It's impossible because the TU may never get to see the type and thus
we can't verify that it is suitable.)

This fixes PR16856.

Reviewers: rsmith, rnk, thakis

Reviewed By: rnk

CC: cfe-commits

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

llvm-svn: 188481

show more ...

[-cxx-abi microsoft] Mangle __uuidof correctly into template parameters

Summary:
It seems that __uuidof introduces a global extern "C" declaration of
type __s_GUID. However, our implementation of _

[-cxx-abi microsoft] Mangle __uuidof correctly into template parameters

Summary:
It seems that __uuidof introduces a global extern "C" declaration of
type __s_GUID. However, our implementation of __uuidof does not provide
such a declaration and thus must open-code the mangling for __uuidof in
template parameters.

This allows us to codegen scoped COM pointers and other such things.

This fixes PR16836.
Depends on D1356.

Reviewers: rnk, cdavis5x, rsmith

Reviewed By: rnk

CC: cfe-commits

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

llvm-svn: 188252

show more ...

Use new llvm::SpecialCaseList API in CodeGenModule

llvm-svn: 188170

[-cxx-abi microsoft] Mangle UUIDs correctly, stick them in the proper section

Revert r188055 which reverted r188053. An unrelated change previously snuck in.

llvm-svn: 188060

Revert "[-cxx-abi microsoft] Mangle UUIDs correctly, stick them in the proper section"

This commit reverts r188053.

It is breaking the build bots.

llvm-svn: 188055

[-cxx-abi microsoft] Mangle UUIDs correctly, stick them in the proper section

We mangled them like:
L___uuid_12345678-1234-1234-1234-123456789abc

We should've mangled them like:
__GUID_12345678_123

[-cxx-abi microsoft] Mangle UUIDs correctly, stick them in the proper section

We mangled them like:
L___uuid_12345678-1234-1234-1234-123456789abc

We should've mangled them like:
__GUID_12345678_1234_1234_1234_123456789abc

Furthermore, they are external symbols.

llvm-svn: 188053

show more ...

Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Stati

Started implementing variable templates. Top level declarations should be fully supported, up to some limitations documented as FIXMEs or TODO. Static data member templates work very partially. Static data member templates of class templates need particular attention...

llvm-svn: 187762

show more ...