Avoid code duplication by calling setAliasAttributes in EmitAliasDefinition.

llvm-svn: 219258

Fix ctor/dtor aliases losing 'dllexport' (for Itanium ABI)

This patch makes sure that the dllexport attribute is transferred to the alias when such alias is created. It only affects the Itanium ABI

Fix ctor/dtor aliases losing 'dllexport' (for Itanium ABI)

This patch makes sure that the dllexport attribute is transferred to the alias when such alias is created. It only affects the Itanium ABI because for the MSVC ABI a workaround is in place to not generate aliases of dllexport ctors/dtors.
A new CodeGenModule function is provided, CodeGenModule::setAliasAttributes, to factor the code for transferring attributes to aliases.

llvm-svn: 218159

show more ...

Add support for putting constructors and destructos in explicit comdats.

There are situations when clang knows that the C1 and C2 constructors
or the D1 and D2 destructors are identical. We already

Add support for putting constructors and destructos in explicit comdats.

There are situations when clang knows that the C1 and C2 constructors
or the D1 and D2 destructors are identical. We already optimize some
of these cases, but cannot optimize it when the GlobalValue is
weak_odr.

The problem with weak_odr is that an old TU seeing the same code will
have a C1 and a C2 comdat with the corresponding symbols. We cannot
suddenly start putting the C2 symbol in the C1 comdat as we cannot
guarantee that the linker will not pick a .o with only C1 in it.

The solution implemented by GCC is to expand the ABI to have a comdat
whose name uses a C5/D5 suffix and always has both symbols. That is
what this patch implements.

llvm-svn: 217874

show more ...

Move emitCXXStructor to CGCXXABI.

A followup patch will address the code duplication.

llvm-svn: 217807

Create a emitCXXStructor function and make the existing emitCXXConstructor and
emitCXXDestructor static helpers.

A next patch will make it a helper in CGCXXABI.

llvm-svn: 217804

Remove a parameter that has been unused since r188481. No behavior change.

llvm-svn: 217386

Add a comment for something that confused me.

llvm-svn: 217384

Better codegen support for DLL attributes being dropped after the first declaration (PR20792)

For the following code:

__declspec(dllimport) int f(int x);
int user(int x) {
return f(x);
}

Better codegen support for DLL attributes being dropped after the first declaration (PR20792)

For the following code:

__declspec(dllimport) int f(int x);
int user(int x) {
return f(x);
}
int f(int x) { return 1; }

Clang will drop the dllimport attribute in the AST, but CodeGen would have
already put it on the LLVM::Function, and that would never get updated.
(The same thing happens for global variables.)

This makes Clang check dropped DLL attribute case each time the LLVM object
is referenced.

This isn't perfect, because we will still get it wrong if the function is
never referenced by codegen after the attribute is dropped, but this handles
the common cases and makes us not fail in the verifier.

llvm-svn: 216699

show more ...

Add a cc1 "dump-coverage-mapping" for testing coverage mapping.

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

llvm-svn: 215258

MS ABI: Aligned tentative definitions don't have CommonLinkage

int __declspec(align(16)) foo; is a tentative definition but the storage
for that variable should not have CommonLinkage.

llvm-svn: 21

MS ABI: Aligned tentative definitions don't have CommonLinkage

int __declspec(align(16)) foo; is a tentative definition but the storage
for that variable should not have CommonLinkage.

llvm-svn: 214828

show more ...

Add coverage mapping generation.

This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis us

Add coverage mapping generation.

This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis using
the execution counts obtained from the instrumentation
based profiling (-fprofile-instr-generate).

llvm-svn: 214752

show more ...

In the case of mangling collisions, make an attempt to note both definitions
involved.

llvm-svn: 214606

Actually fix problem with modules buildbot this time.

llvm-svn: 214579

[Sanitizer] Introduce SanitizerMetadata class.

It is responsible for generating metadata consumed by sanitizer instrumentation
passes in the backend. Move several methods from CodeGenModule to Sanit

[Sanitizer] Introduce SanitizerMetadata class.

It is responsible for generating metadata consumed by sanitizer instrumentation
passes in the backend. Move several methods from CodeGenModule to SanitizerMetadata.
For now the class is stateless, but soon it won't be the case.

Instead of creating globals providing source-level information to ASan, we will create
metadata nodes/strings which will be turned into actual global variables in the
backend (if needed).

No functionality change.

llvm-svn: 214564

show more ...

Re-commit r214547 with tests fixed. Hopefully all the bots will be happy now.
Original message:

Fix iterator invalidation issues that are breaking my modules buildbot's
bootstrap.

llvm-svn: 214555

Revert r214547 due to test breakage.

llvm-svn: 214549

Fix iterator invalidation issues that are breaking my modules buildbot's bootstrap.

llvm-svn: 214547

[modules] Remove IRGen special case for emitting implicit special members if
they're somehow missing a body. Looks like this was left behind when the loop
was generalized, and it's not been problemat

[modules] Remove IRGen special case for emitting implicit special members if
they're somehow missing a body. Looks like this was left behind when the loop
was generalized, and it's not been problematic before because without modules,
a used, implicit special member function declaration must be a definition.

This was resulting in us trying to emit a constructor declaration rather than
a definition, and producing a constructor missing its member initializers.

llvm-svn: 214473

show more ...

PR20473: Don't "deduplicate" string literals with the same value but different
lengths! In passing, simplify string literal deduplication by relying on LLVM
to deduplicate the underlying constant val

PR20473: Don't "deduplicate" string literals with the same value but different
lengths! In passing, simplify string literal deduplication by relying on LLVM
to deduplicate the underlying constant values.

llvm-svn: 214222

show more ...

Make sure globals created by UBSan are not instrumented by ASan.

Summary:
This change adds description of globals created by UBSan
instrumentation (UBSan handlers, type descriptors, filenames) to
ll

Make sure globals created by UBSan are not instrumented by ASan.

Summary:
This change adds description of globals created by UBSan
instrumentation (UBSan handlers, type descriptors, filenames) to
llvm.asan.globals metadata, effectively "blacklisting" them. This can
dramatically decrease the data section in binaries built with UBSan+ASan,
as UBSan tends to create a lot of handlers, and ASan instrumentation
increases the global size to at least 64 bytes.

Test Plan: clang regression test suite

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits, byoungyoung, kcc

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

llvm-svn: 213392

show more ...

MS compatibility: always emit dllexported in-class initialized static data members (PR20140)

This makes us emit dllexported in-class initialized static data members (which
are treated as definitions

MS compatibility: always emit dllexported in-class initialized static data members (PR20140)

This makes us emit dllexported in-class initialized static data members (which
are treated as definitions in MSVC), even when they're not referenced.

It also makes their special linkage reflected in the GVA linkage instead of
getting massaged in CodeGen.

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

llvm-svn: 213304

show more ...

[ASan] Collect unmangled names of global variables in Clang to print them in error reports.

Currently ASan instrumentation pass creates a string with global name
for each instrumented global (to inc

[ASan] Collect unmangled names of global variables in Clang to print them in error reports.

Currently ASan instrumentation pass creates a string with global name
for each instrumented global (to include global names in the error report). Global
name is already mangled at this point, and we may not be able to demangle it
at runtime (e.g. there is no __cxa_demangle on Android).

Instead, create a string with fully qualified global name in Clang, and pass it
to ASan instrumentation pass in llvm.asan.globals metadata. If there is no metadata
for some global, ASan will use the original algorithm.

This fixes https://code.google.com/p/address-sanitizer/issues/detail?id=264.

llvm-svn: 212872

show more ...

Be more specific about return types of some methods.

This would allow to call addCompilerUsedGlobal on some
Clang-generated globals.

llvm-svn: 212767

Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.

Turn llvm::SpecialCaseList into a simple class that parses text files in
a specified format and knows nothing about LLVM

Decouple llvm::SpecialCaseList text representation and its LLVM IR semantics.

Turn llvm::SpecialCaseList into a simple class that parses text files in
a specified format and knows nothing about LLVM IR. Move this class into
LLVMSupport library. Implement two users of this class:
* DFSanABIList in DFSan instrumentation pass.
* SanitizerBlacklist in Clang CodeGen library.
The latter will be modified to use actual source-level information from frontend
(source file names) instead of unstable LLVM IR things (LLVM Module identifier).

Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils.

No functionality change.

llvm-svn: 212643

show more ...

[Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule

Get rid of cached CodeGenModule::SanOpts, which was used to turn off
sanitizer codegen options if current LLVM Module is blacklis

[Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModule

Get rid of cached CodeGenModule::SanOpts, which was used to turn off
sanitizer codegen options if current LLVM Module is blacklisted, and use
plain LangOpts.Sanitize instead.

1) Some codegen decisions (turning TBAA or writable strings on/off)
shouldn't depend on the contents of blacklist.

2) llvm.asan.globals should *always* be created, even if the module
is blacklisted - soon Clang's CodeGen where we read sanitizer
blacklist files, so we should properly report which globals are
blacklisted to the backend.

llvm-svn: 212499

show more ...