History log of /llvm-project/clang/lib/CodeGen/CodeGenModule.cpp (Results 1151 – 1175 of 2157)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 82e95a3c 19-Nov-2014 David Blaikie <dblaikie@gmail.com>

Update for LLVM API change to make Small(Ptr)Set::insert return pair<iterator, bool> as per the C++ standard's associative container concept.

llvm-svn: 222335


# 3c8c46ef 19-Nov-2014 David Blaikie <dblaikie@gmail.com>

clang-format a recent commit I made

llvm-svn: 222317


# 13156b68 19-Nov-2014 David Blaikie <dblaikie@gmail.com>

Standardize on StringMap::insert, removing uses of StringMap::GetOrCreateValue.

llvm-svn: 222306


# 90ca05e5 18-Nov-2014 Justin Hibbits <jrh29@alumni.cwru.edu>

Add PIC-level support to Clang.

Summary:
This distinguishes between -fpic and -fPIC now, with the additions in LLVM for
PIC level support.

Test Plan: No regressions

Reviewers: echristo, rafael

Re

Add PIC-level support to Clang.

Summary:
This distinguishes between -fpic and -fPIC now, with the additions in LLVM for
PIC level support.

Test Plan: No regressions

Reviewers: echristo, rafael

Reviewed By: rafael

Subscribers: rnk, emaste, llvm-commits

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

llvm-svn: 222227

show more ...


# 800821a3 12-Nov-2014 Fariborz Jahanian <fjahanian@apple.com>

[Objective-C++ IRGen] do not generate .cxx_construct
for class that contains trivially-constructible struct ivar.
rdar://18950072

llvm-svn: 221823


# 2b1f278e 11-Nov-2014 Duncan P. N. Exon Smith <dexonsmith@apple.com>

Revert "IR: MDNode => Value: Update for LLVM API change in r221375"

This reverts commit r221376.

The API change was reverted in r221711.

llvm-svn: 221712


# 9772000a 11-Nov-2014 Alexey Bataev <a.bataev@hotmail.com>

[OPENMP] Codegen for threadprivate variables
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Ori

[OPENMP] Codegen for threadprivate variables
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002

llvm-svn: 221663

show more ...


# edf99a92 07-Nov-2014 Alexey Samsonov <vonosmas@gmail.com>

Introduce a SanitizerKind enum to LangOptions.

Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled san

Introduce a SanitizerKind enum to LangOptions.

Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.

No functionality change.

llvm-svn: 221558

show more ...


# 2b049767 05-Nov-2014 Duncan P. N. Exon Smith <dexonsmith@apple.com>

IR: MDNode => Value: Update for LLVM API change in r221375

llvm-svn: 221376


# 606bd6dc 03-Nov-2014 Hans Wennborg <hans@hanshq.net>

Don't dllimport inline functions when targeting MinGW (PR21366)

It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with

Don't dllimport inline functions when targeting MinGW (PR21366)

It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.

To fix this, make Clang never dllimport inline functions when targeting
MinGW.

llvm-svn: 221154

show more ...


# b9bd6fb3 01-Nov-2014 David Majnemer <david.majnemer@gmail.com>

CodeGen: Virtual dtor thunks shouldn't have this marked as 'returned'

The ARM ABI virtual destructor thunks cannot be marked as 'returned'
because they return undef.

llvm-svn: 221042


# a0ac3c2b 17-Oct-2014 Alexey Samsonov <vonosmas@gmail.com>

[ASan] Improve blacklisting of global variables.

This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, o

[ASan] Improve blacklisting of global variables.

This commit changes the way we blacklist global variables in ASan.
Now the global is excluded from instrumentation (either regular
bounds checking, or initialization-order checking) if:

1) Global is explicitly blacklisted by its mangled name.
This part is left unchanged.

2) SourceLocation of a global is in blacklisted source file.
This changes the old behavior, where instead of looking at the
SourceLocation of a variable we simply considered llvm::Module
identifier. This was wrong, as identifier may not correspond to
the file name, and we incorrectly disabled instrumentation
for globals coming from #include'd files.

3) Global is blacklisted by type.
Now we build the type of a global variable using Clang machinery
(QualType::getAsString()), instead of llvm::StructType::getName().

After this commit, the active users of ASan blacklist files
may have to revisit them (this is a backwards-incompatible change).

llvm-svn: 220097

show more ...


# 1444bb9f 17-Oct-2014 Alexey Samsonov <vonosmas@gmail.com>

SanitizerBlacklist: blacklist functions by their source location.

This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and tur

SanitizerBlacklist: blacklist functions by their source location.

This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:

1) Function is explicitly blacklisted by its mangled name.
This part is not changed.

2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.

After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.

After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.

I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).

llvm-svn: 219997

show more ...


# 899ded9c 16-Oct-2014 Hans Wennborg <hans@hanshq.net>

MS Compat: mark globals emitted in read-only sections const

They cannot be written to, so marking them const makes sense and may improve
optimisation.

As a side-effect, SectionInfos has to be moved

MS Compat: mark globals emitted in read-only sections const

They cannot be written to, so marking them const makes sense and may improve
optimisation.

As a side-effect, SectionInfos has to be moved from Sema to ASTContext.

It also fixes this problem, that occurs when compiling ATL:

warning LNK4254: section 'ATL' (C0000040) merged into '.rdata' (40000040) with different attributes

The ATL headers are putting variables in a special section that's marked
read-only. However, Clang currently can't model that read-onlyness in the IR.
But, by making the variables const, the section does become read-only, and
the linker warning is avoided.

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

llvm-svn: 219960

show more ...


# bb525f7c 15-Oct-2014 David Majnemer <david.majnemer@gmail.com>

CodeGen: Don't drop thread_local when emitting __thread aliases

CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.

Even if the definition was already emitt

CodeGen: Don't drop thread_local when emitting __thread aliases

CodeGen wouldn't mark the aliasee as thread_local if the aliasee was a
tentative definition.

Even if the definition was already emitted, it would never mark the
alias as thread_local.

This fixes PR21288.

llvm-svn: 219859

show more ...


# 0b15e34b 15-Oct-2014 Alexey Samsonov <vonosmas@gmail.com>

Move SanitizerBlacklist object from CodeGenModule to ASTContext.

Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the

Move SanitizerBlacklist object from CodeGenModule to ASTContext.

Soon we'll need to have access to blacklist before the CodeGen
phase (see http://reviews.llvm.org/D5687), so parse and construct
the blacklist earlier.

llvm-svn: 219857

show more ...


# ae5804f3 15-Oct-2014 Alexey Samsonov <vonosmas@gmail.com>

Move -fsanitize-blacklist to LangOpts from CodeGenOpts. NFC.

After http://reviews.llvm.org/D5687 is submitted, we will need
SanitizerBlacklist before the CodeGen phase, so make it a LangOpt
(as it w

Move -fsanitize-blacklist to LangOpts from CodeGenOpts. NFC.

After http://reviews.llvm.org/D5687 is submitted, we will need
SanitizerBlacklist before the CodeGen phase, so make it a LangOpt
(as it will actually affect ABI / class layout).

llvm-svn: 219842

show more ...


# ec474780 09-Oct-2014 Alexey Bataev <a.bataev@hotmail.com>

Fix for bug http://llvm.org/PR17427.
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.

Fix for bug http://llvm.org/PR17427.
Assertion failed: "Computed __func__ length differs from type!"
Reworked PredefinedExpr representation with internal StringLiteral field for function declaration.
Differential Revision: http://reviews.llvm.org/D5365

llvm-svn: 219393

show more ...


# fcfbcc6d 08-Oct-2014 Rafael Espindola <rafael.espindola@gmail.com>

Avoid code duplication by calling setAliasAttributes in EmitAliasDefinition.

llvm-svn: 219258


# c4fb8ca7 19-Sep-2014 Dario Domizioli <dario.domizioli@gmail.com>

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 ...


# 1e4df92f 16-Sep-2014 Rafael Espindola <rafael.espindola@gmail.com>

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 ...


# 91f68b43 15-Sep-2014 Rafael Espindola <rafael.espindola@gmail.com>

Move emitCXXStructor to CGCXXABI.

A followup patch will address the code duplication.

llvm-svn: 217807


# 02b77f42 15-Sep-2014 Rafael Espindola <rafael.espindola@gmail.com>

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


# 17d3a2c3 08-Sep-2014 Nico Weber <nicolasweber@gmx.de>

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

llvm-svn: 217386


# dfa274eb 08-Sep-2014 Nico Weber <nicolasweber@gmx.de>

Add a comment for something that confused me.

llvm-svn: 217384


1...<<41424344454647484950>>...87