Commit Graph

10 Commits

Author SHA1 Message Date
Hans Wennborg 93f7547260 Try harder to not inline dllimport functions referencing non-dllimport functions
In r246338, code was added to check for this, but it failed to take into
account implicit destructor invocations because those are not reflected
in the AST. This adds a separate check for them.

llvm-svn: 281395
2016-09-13 21:08:20 +00:00
Denis Zobnin eebc4af0ed [ms][dll] #26935 Defining a dllimport function should cause it to be exported
If we have some function with dllimport attribute and then we have the function
definition in the same module but without dllimport attribute we should add
dllexport attribute to this function definition.
The same should be done for variables.

Example:
struct __declspec(dllimport) C3 {
  ~C3();
};
C3::~C3() {;} // we should export this definition.

Patch by Andrew V. Tischenko

Differential revision: http://reviews.llvm.org/D18953

llvm-svn: 270686
2016-05-25 11:32:42 +00:00
Hans Wennborg 606bd6dcc5 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
2014-11-03 14:24:45 +00:00
Hal Finkel a2347baaec Mark C++ reference parameters as dereferenceable
Because references must be initialized using some evaluated expression, they
must point to something, and a callee can assume the reference parameter is
dereferenceable. Taking advantage of a new attribute just added to LLVM, mark
them as such.

Because dereferenceability in addrspace(0) implies nonnull in the backend, we
don't need both attributes. However, we need to know the size of the object to
use the dereferenceable attribute, so for incomplete types we still emit only
nonnull.

llvm-svn: 213386
2014-07-18 15:52:10 +00:00
Hans Wennborg 56fc62bf01 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
2014-07-17 20:25:23 +00:00
Nico Rieck 968bd69768 Fix some minor typos in tests
llvm-svn: 209830
2014-05-29 16:57:18 +00:00
Nico Rieck b4662c3e5a MS ABI: Emit static data members with proper linkage
llvm-svn: 209826
2014-05-29 16:50:46 +00:00
Nick Lewycky 9b46eb8112 Add 'nonnull' parameter or return attribute when producing an llvm pointer type in a function type where the C++ type is a reference. Update the tests.
llvm-svn: 209723
2014-05-28 09:56:42 +00:00
Hans Wennborg 275efb9e50 Don't dllimport/export destructor variants implemented by thunks.
MSVC doesn't export these functions, so trying to import them doesnt' work.
Also, don't let any dll attributes on the CXXDestructorDecl influence the
thunk's linkage -- they should always be linkonce_odr.

This takes care of the FIXME's for this in Nico's tests.

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

llvm-svn: 209706
2014-05-28 01:52:23 +00:00
Nico Rieck 755a36f593 IRGen: Add more tests for dll attributes
llvm-svn: 209596
2014-05-25 10:34:16 +00:00