Commit Graph

74 Commits

Author SHA1 Message Date
Rafael Espindola c7bd85424c Suppress clang warnings in a codegen test.
This makes the output of FileCheck way easier to read since this test hits
many warnings.

llvm-svn: 225322
2015-01-06 23:53:13 +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
Hans Wennborg ec53c29932 Don't emit strong vtable definitions for imported classes with key functions (PR21355)
Clang would previously assert on the following code when targeting MinGW:

  struct __declspec(dllimport) S {
      virtual ~S();
  };
  S::~S() {}

Because ~S is a key function and the class is dllimport, we would try to emit a
strong definition of the vtable, with dllimport - which is a conflict. We
should not emit strong vtable definitions for imported classes.

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

llvm-svn: 220532
2014-10-23 22:40:46 +00:00
David Majnemer 040fa34bec MS ABI: Use '1' (instead of '0') relative scope discriminators
This changes the scope discriminator's behavior to start at '1' instead
of '0'.  Symbol table diffing, for ABI compatibility testing, kept
finding these as false positives.

llvm-svn: 219075
2014-10-05 06:44:53 +00:00
Hans Wennborg c2b7f7a6ab Don't assert on different DLL attributes in template and explicit instantiation (PR20137)
We would previously assert (a decl cannot have two DLL attributes) on this code:

  template <typename T> struct __declspec(dllimport) S { T f() { return T(); } };
  template struct __declspec(dllexport) S<int>;

The problem was that when instantiating, we would take the attribute from the
template even if the instantiation itself already had an attribute.

Also, don't inherit DLL attributes from the template to its members before
instantiation, as the attribute may change.

I couldn't figure out what MinGW does here, so I'm leaving that open. At least
we're not asserting anymore.

llvm-svn: 216340
2014-08-24 00:12:36 +00:00
Hans Wennborg 205c39bb6b MS ABI: Inherit DLL attributes to partial class template specializations
llvm-svn: 216333
2014-08-23 22:34:43 +00:00
Hans Wennborg 7c4851e3ad Don't drop dllimport from qualified friend redeclarations (PR20512)
This matches MSVC's logic, which seems to be that when the friend
declaration is qualified, it cannot be a declaration of a new symbol
and so the dll linkage doesn't change.

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

llvm-svn: 214774
2014-08-04 20:54:39 +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
Alp Toker 958027b698 Fix typos
Also consolidate 'backward compatibility'

llvm-svn: 212974
2014-07-14 19:42:55 +00:00
Hans Wennborg 82dd877e8a Don't allow dllimport variables in constant initializers
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.

  __declspec(dllimport) extern const char foo[];
  const char* f() {
    static const char* const arr[] = { foo };
    return arr[0];
  }

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

llvm-svn: 211736
2014-06-25 22:19:48 +00:00
Hans Wennborg 9bea9cc73b MS ABI: Propagate class-level DLL attributes to class template specialization bases (PR11170)
Consider the following code:

  template <typename T> class Base {};
  class __declspec(dllexport) class Derived : public Base<int> {}

When the base of an exported or imported class is a class template
specialization, MSVC will propagate the dll attribute to the base.
In the example code, Base<int> becomes a dllexported class.

This commit makes Clang do the proopagation when the base hasn't been
instantiated yet, and warns about it being unsupported otherwise.
This is different from MSVC, which allows changing a specialization
back and forth between dllimport and dllexport and seems to let the
last one win. Changing the dll attribute after instantiation would be
hard for us, and doesn't seem to come up in practice, so I think this
is a reasonable limitation to have.

MinGW doesn't do this kind of propagation.

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

llvm-svn: 211725
2014-06-25 18:25:57 +00:00
Hans Wennborg 5e64528195 MS ABI: Ignore dll attributes on partial template specializations
llvm-svn: 211648
2014-06-24 23:57:13 +00:00
Hans Wennborg ef2272c49e Inherit dll attributes to static locals
This makes us handle static locals in exported/imported functions correctly.

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

llvm-svn: 211173
2014-06-18 15:55:13 +00:00
Hans Wennborg e8ad3839a1 Don't inherit dllimport to inline move assignment operators
Current MSVC versions don't have move assignment operators, so we
can't rely on them being available in the dll. If we have the
definition, we can just use that directly. This breaks pointer
equality, but should work fine otherwise.

When there is an MSVC version that supports move assignment,
we can key this off the -fmsc-ver option.

http://reviews.llvm.org/D4105

llvm-svn: 210715
2014-06-11 22:44:39 +00:00
Hans Wennborg 91ebe6eb04 Improve checking for dynamic initializers of dllimport fields in template instantiation
We would previously assert if the initializer was dependent. I also think that
checking isConstantInitializer is more correct here than checkInitIsICE.

llvm-svn: 210505
2014-06-10 00:55:51 +00:00
Hans Wennborg cd95922bd1 Allow definition of dllimport static fields in partial specializations (PR19956)
This expands the logic from r210141 to cover partial specializations too.

llvm-svn: 210484
2014-06-09 18:30:28 +00:00
Hans Wennborg c94391d3bf MS ABI: Update the thunk linkage computation
As suggested by Reid:

 - class has GVA_Internal linkage -> internal
 - thunk has return adjustment -> weak_odr, to handle evil corner case [1]
 - all other normal methods -> linkonce_odr

 1. Evil corner case:

  struct Incomplete;
  struct A { int a; virtual A *bar(); };
  struct B { int b; virtual B *foo(Incomplete); };
  struct C : A, B { int c; virtual C *foo(Incomplete); };
  C c;

Here, the thunk for C::foo() will be emitted when C::foo() is defined, which
might be in a different translation unit, so it needs to be weak_odr.

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

llvm-svn: 210368
2014-06-06 20:04:01 +00:00
Hans Wennborg 910640b5d8 Don't dynamically initialize dllimport vars (PR19933)
They should be initialized when they're exported.

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

llvm-svn: 210217
2014-06-04 21:09:46 +00:00
Hans Wennborg e9af316423 Downgrade "definition of dllimport static field" error to warning for class templates (PR19902)
This allows us to compile the following kind of code, which occurs in MSVC
headers:

  template <typename> struct S {
    __declspec(dllimport) static int x;
  };
  template <typename T> int S<T>::x;

The definition works similarly to a dllimport inline function definition and
gets available_externally linkage.

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

llvm-svn: 210141
2014-06-04 00:18:41 +00:00
Hans Wennborg da24e9cee3 Itanium ABI: Update getAddrOfVTable to set the DLL storage class for vtables
This corresponds to the same change for the MS ABI in r209908.

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

llvm-svn: 210054
2014-06-02 23:13:03 +00:00
Hans Wennborg 853ae94660 Start adding support for dllimport/dllexport on classes (PR11170)
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.

This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.

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

llvm-svn: 209908
2014-05-30 16:59:42 +00:00
Nico Rieck 755a36f593 IRGen: Add more tests for dll attributes
llvm-svn: 209596
2014-05-25 10:34:16 +00:00
Hans Wennborg 7f26fa6715 Allow dllimport on function definitions when they're template instantiations
llvm-svn: 209157
2014-05-19 20:14:13 +00:00
Hans Wennborg b0f2f146bb Allow dllimport/dllexport on inline functions and adjust the linkage.
This is a step towards handling these attributes on classes (PR11170).

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

llvm-svn: 208925
2014-05-15 22:07:49 +00:00