It is not needed after LLVM r327734. Now it will be easier to copy-paste
IR symbol names from Clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@327738 91177308-0d34-0410-b5e6-96231b3b80d8
The tests that failed on a windows host have been fixed.
Original message:
Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@325940 91177308-0d34-0410-b5e6-96231b3b80d8
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@325915 91177308-0d34-0410-b5e6-96231b3b80d8
explicitly instantiated, still emit it with each use.
We don't emit a definition of the member with an explicit instantiation
definition (and indeed it appears that we're not allowed to, since an explicit
instantiation definition does not constitute an odr-use and only odr-use
permits definition for defaulted special members). So we still need to emit a
weak definition with each use.
This also makes defaulted-in-class declarations behave more like
implicitly-declared special members, which matches their design intent.
And it matches the way this problem was solved in GCC.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318474 91177308-0d34-0410-b5e6-96231b3b80d8
As Mehdi put it, entities should either be
available_externally+weak_odr, or linkonce_odr+linkonce_odr. While some
functions are emitted a_e/weak, their local variables were emitted
a_e/linkonce_odr.
While it might be nice to emit them a_e/weak, the Itanium ABI (& best
guess at MSVC's behavior as well) requires the local to be
linkonce/linkonce.
Reviewers: rsmith, mehdi_amini
Differential Revision: https://reviews.llvm.org/D29233
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@293344 91177308-0d34-0410-b5e6-96231b3b80d8
Much to my surprise, '-disable-llvm-optzns' which I thought was the
magical flag I wanted to get at the raw LLVM IR coming out of Clang
deosn't do that. It still runs some passes over the IR. I don't want
that, I really want the *raw* IR coming out of Clang and I strongly
suspect everyone else using it is in the same camp.
There is actually a flag that does what I want that I didn't know about
called '-disable-llvm-passes'. I suspect many others don't know about it
either. It both does what I want and is much simpler.
This removes the confusing version and makes that spelling of the flag
an alias for '-disable-llvm-passes'. I've also moved everything in Clang
to use the 'passes' spelling as it seems both more accurate (*all* LLVM
passes are disabled, not just optimizations) and much easier to remember
and spell correctly.
This is part of simplifying how Clang drives LLVM to make it cleaner to
wire up to the new pass manager.
Differential Revision: https://reviews.llvm.org/D28047
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290392 91177308-0d34-0410-b5e6-96231b3b80d8
Also make explicit instantiation decls not apply to nested classes when
targeting MSVC. That dll attributes are not inherited by inner classes
might be the explanation for MSVC's behaviour here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270897 91177308-0d34-0410-b5e6-96231b3b80d8
Their linkage can change if they are later explicitly instantiated. We would
previously emit such functions eagerly (as opposed to lazily on first use) if
they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the
explicit instantiation.
This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method
with two new ones: MustBeEmitted() and MayBeEmittedEagerly().
Differential Revision: http://reviews.llvm.org/D6674
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225570 91177308-0d34-0410-b5e6-96231b3b80d8
after we've already instantiated a definition for the function, pass it to the
ASTConsumer again so that it knows the specialization kind has changed and can
update the function's linkage.
This only matters if we instantiate the definition of the function before we
reach the end of the TU; this can happen in at least three different ways:
C++11 constexpr functions, C++14 deduced return types, and functions
instantiated within modules.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207152 91177308-0d34-0410-b5e6-96231b3b80d8
weak linkage. Also, fix a problem where global weak variables
with non-trivial initializers were getting guard variables, or at
least were checking for them and then crashing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@129342 91177308-0d34-0410-b5e6-96231b3b80d8
templates when only the declaration is in scope. This requires deferring the
instantiation to be lazy, and ensuring the definition is required for that
translation unit. We re-use the existing pending instantiation queue,
previously only used to track implicit instantiations which were required to be
lazy. Fixes PR7979.
A subsequent change will rename *PendingImplicitInstantiations to
*PendingInstatiations for clarity given its broader role.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112037 91177308-0d34-0410-b5e6-96231b3b80d8
iterations of this patch gave explicit template instantiation
link-once ODR linkage, which permitted the back end to eliminate
unused symbols. Weak ODR linkage still requires the symbols to be
generated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98441 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86430 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation of a member function template or member function of a
class template to be out-of-line if the definition of that function
template or member function was defined out-of-line. This ensures that
we get the correct linkage for explicit instantiations of out-of-line
definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81562 91177308-0d34-0410-b5e6-96231b3b80d8
templates. We now distinguish between an explicit instantiation
declaration and an explicit instantiation definition, and know not to
instantiate explicit instantiation declarations. Unfortunately, there
is some remaining confusion w.r.t. instantiation of out-of-line member
function definitions that causes trouble here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81053 91177308-0d34-0410-b5e6-96231b3b80d8
Reid Kleckner