summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/dllimport.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't emit strong vtable definitions for imported classes with key functions ↵Hans Wennborg2014-10-231-0/+12
| | | | | | | | | | | | | | | | | | | (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
* MS ABI: Use '1' (instead of '0') relative scope discriminatorsDavid Majnemer2014-10-051-1/+1
| | | | | | | | 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
* Don't assert on different DLL attributes in template and explicit ↵Hans Wennborg2014-08-241-0/+6
| | | | | | | | | | | | | | | | | | | | 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
* MS ABI: Inherit DLL attributes to partial class template specializationsHans Wennborg2014-08-231-0/+9
| | | | llvm-svn: 216333
* Don't drop dllimport from qualified friend redeclarations (PR20512)Hans Wennborg2014-08-041-0/+14
| | | | | | | | | | 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
* Mark C++ reference parameters as dereferenceableHal Finkel2014-07-181-2/+2
| | | | | | | | | | | | | | 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
* Fix typosAlp Toker2014-07-141-1/+1
| | | | | | Also consolidate 'backward compatibility' llvm-svn: 212974
* Don't allow dllimport variables in constant initializersHans Wennborg2014-06-251-0/+8
| | | | | | | | | | | | | | | | | 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
* MS ABI: Propagate class-level DLL attributes to class template ↵Hans Wennborg2014-06-251-0/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MS ABI: Ignore dll attributes on partial template specializationsHans Wennborg2014-06-241-1/+14
| | | | llvm-svn: 211648
* Inherit dll attributes to static localsHans Wennborg2014-06-181-0/+9
| | | | | | | | This makes us handle static locals in exported/imported functions correctly. Differential Revision: http://reviews.llvm.org/D4136 llvm-svn: 211173
* Don't inherit dllimport to inline move assignment operatorsHans Wennborg2014-06-111-0/+11
| | | | | | | | | | | | | | 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
* Improve checking for dynamic initializers of dllimport fields in template ↵Hans Wennborg2014-06-101-0/+7
| | | | | | | | | 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
* Allow definition of dllimport static fields in partial specializations (PR19956)Hans Wennborg2014-06-091-1/+11
| | | | | | This expands the logic from r210141 to cover partial specializations too. llvm-svn: 210484
* MS ABI: Update the thunk linkage computationHans Wennborg2014-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | 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
* Don't dynamically initialize dllimport vars (PR19933)Hans Wennborg2014-06-041-10/+32
| | | | | | | | They should be initialized when they're exported. Differential Revision: http://reviews.llvm.org/D4020 llvm-svn: 210217
* Downgrade "definition of dllimport static field" error to warning for class ↵Hans Wennborg2014-06-041-0/+9
| | | | | | | | | | | | | | | | | | | 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
* Itanium ABI: Update getAddrOfVTable to set the DLL storage class for vtablesHans Wennborg2014-06-021-5/+19
| | | | | | | | This corresponds to the same change for the MS ABI in r209908. Differential Revision: http://reviews.llvm.org/D3993 llvm-svn: 210054
* Start adding support for dllimport/dllexport on classes (PR11170)Hans Wennborg2014-05-301-8/+74
| | | | | | | | | | | | | | | | 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
* IRGen: Add more tests for dll attributesNico Rieck2014-05-251-18/+496
| | | | llvm-svn: 209596
* Allow dllimport on function definitions when they're template instantiationsHans Wennborg2014-05-191-1/+1
| | | | llvm-svn: 209157
* Allow dllimport/dllexport on inline functions and adjust the linkage.Hans Wennborg2014-05-151-0/+25
This is a step towards handling these attributes on classes (PR11170). Differential Revision: http://reviews.llvm.org/D3772 llvm-svn: 208925
OpenPOWER on IntegriCloud