This is the next step in setting dso_local for COFF.
The patches changes setGVProperties to first set dllimport/dllexport
and changes a few cases that were setting dllimport/dllexport
manually. With this a few more GVs are marked dso_local.
llvm-svn: 326397
Fix for PR32992. Static const classes not exported.
Patch by zahiraam!
(This re-lands the commit, but using S.MarkVariableReferenced instead of
S.PendingInstantiations.push_back, and with an additional test.)
Differential Revision: https://reviews.llvm.org/D42968
llvm-svn: 326089
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.
llvm-svn: 325940
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.
llvm-svn: 325915
This broke the Chromium build on Windows; see https://crbug.com/812231
> Fix for PR32992. Static const classes not exported.
>
> Patch by zahiraam!
>
> Differential Revision: https://reviews.llvm.org/D42968
llvm-svn: 325133
whether they have an initializer.
We cannot distinguish between a declaration of a variable template
specialization and a definition of one that lacks an initializer without this,
and would previously mistake the latter for the former.
llvm-svn: 319605
This is a re-commit of r315025, but making sure to only apply this to
specializations of class template member functions; i.e. not when the function
itself is a template.
llvm-svn: 315330
Setting dllexport on a declaration has no effect, as we do not emit export
directives for declarations.
Part of the fix for PR32334.
Differential Revision: https://reviews.llvm.org/D31162
llvm-svn: 298330
In the case where the template class itself is already `dllexport`, the
implicit instantiation will have already emitted all members. When we
check the explicit instantiation definition, the `Specialization` will
have inherited the `dllexport` attribute, so we'll attempt to emit all
members for a second time, which causes an assertion failure. Restrict
the exporting to when the `dllexport` attribute is newly introduced by
the explicit instantiation definition.
Fixes PR31608.
Differential Revision: https://reviews.llvm.org/D28590
llvm-svn: 291877
Use the canonical decl in pointer comparisons with the default
constructor closure decl. Otherwise we don't produce the correct
"@@QAEXXZ" mangling, which essentially means "void(void) thiscall public
instance method".
llvm-svn: 291448
Summary:
Replace some old code that probably pre-dated the change to delay
emission of dllexported code until after the closing brace of the
outermost record type. Only uninstantiated default argument expressions
need to be handled now. It is enough to instantiate default argument
expressions when instantiating dllexported default ctors. This also
fixes some double-diagnostic issues in this area.
Fixes PR31500
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28274
llvm-svn: 291045
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
llvm-svn: 290392
In a future change, this representation will allow us to use the new inrange
annotation on getelementptr to allow the optimizer to split vtable groups.
Differential Revision: https://reviews.llvm.org/D22296
llvm-svn: 289584
On MSVC, if an implicit instantiation already exists and an explicit
instantiation definition with a DLL attribute is created, the DLL
attribute still takes effect. Make clang match this behavior for
exporting.
Differential Revision: https://reviews.llvm.org/D26657
llvm-svn: 288682
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.
llvm-svn: 270897
This matches what MSVC does, and should make compiles faster by avoiding to
unnecessarily emit a lot of code.
Differential Revision: http://reviews.llvm.org/D20608
llvm-svn: 270748
Clang doesn't dllexport defaulted special member function defaulted
inside class but does it if they defaulted outside class. MSVC doesn't
make any distinction where they were defaulted. Also MSVC 2013 and 2015
export different set of members. MSVC2015 doesn't emit trivial defaulted
x-tors but does emit copy assign operator.
Differential revision: http://reviews.llvm.org/D20422
llvm-svn: 270535
Clang creates implicit move constructor/assign operator in all cases if
there is std=c++11. But MSVC supports such generation starting from
version 1900 only. As result we have some binary incompatibility.
Differential Revision: http://reviews.llvm.org/D19156
Patch by Andrew V. Tischenko
llvm-svn: 269400
Summary: ...as that is apparently what MSVC does
Reviewers: rnk
Patch by Stephan Bergmann
Differential Revision: http://reviews.llvm.org/D15267
llvm-svn: 263738
Summary:
This change just adds tests for some corner cases of dllimport/dllexport,
primarily for some static methods.
We plan to enable dllimport/dllexport support for the PS4, and these
additional tests are for points we previously were testing internally.
-Warren Ristow
SN Systems - Sony Computer Entertainment Group
Reviewers: rnk
Subscribers: silvas
Differential Revision: http://reviews.llvm.org/D17775
llvm-svn: 262442
Relands r260194 with a fix. If we have a template that transitions from
an extern template to an explicitly instantiated dllexport template, we
would add that class to the delayed exported class list without flushing
it.
For explicit instantiations, we can just flush the list of delayed
classes immediately. We don't have to worry about the bug fixed in
r260194 in this case because explicit instantiations can only occur at
file and namespace scope.
Fixes PR26490.
llvm-svn: 262056
This enables Clang to correctly handle code such as:
struct __declspec(dllexport) S {
int x = 42;
};
where it would otherwise error due to trying to generate the default
constructor before the in-class initializer for x has been parsed.
Differential Revision: http://reviews.llvm.org/D11850
llvm-svn: 245139
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
llvm-svn: 239375
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
This is work towards fixing PR23770.
llvm-svn: 239373
This is a follow-up to r238266. It turned out structors are codegened through a different path,
and didn't get the storage class set in EmitGlobalFunctionDefinition.
llvm-svn: 238443
Previously, we wouldn't call checkDLLAttribute() after the class template
specialization definition if the class template was already instantiated
by an explicit class template specialization declaration.
llvm-svn: 238266
Note: __declspec is also temporarily enabled when compiling for a CUDA target because there are implementation details relying on __declspec(property) support currently. When those details change, __declspec should be disabled for CUDA targets.
llvm-svn: 238238
The MSVC 2015 ABI utilizes a rather straightforward adaptation of the
algorithm found in the appendix of N2382. While we are here, implement
support for emitting cleanups if an exception is thrown while we are
intitializing a static local variable.
llvm-svn: 236697
For example, a function taking a parameter with internal linkage will
itself have internal linkage since it cannot be called outside the
translation unit.
Differential Revision: http://reviews.llvm.org/D9182
llvm-svn: 235471
Previously, we would error out on this code because the default argument
wasn't parsed until the end of Outer:
struct __declspec(dllexport) Outer {
struct __declspec(dllexport) Inner {
Inner(void *p = 0);
};
};
Now we do the checking on the closing brace of Outer instead of Inner.
llvm-svn: 232519
The MS ABI utilizes a compiler generated function called the "vector
constructor iterator" to construct arrays of objects with
non-trivial constructors/destructors. For this to work, the constructor
must follow a specific calling convention. A thunk must be created if
the default constructor has default arguments, is variadic or is
otherwise incompatible. This thunk is called the default constructor
closure.
N.B. Default constructor closures are only generated if the default
constructor is exported because clang itself does not utilize vector
constructor iterators. Failing to export the default constructor
closure will result in link/load failure if a translation unit compiled
with MSVC is on the import side.
Differential Revision: http://reviews.llvm.org/D8331
llvm-svn: 232229
