summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/dllexport.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [opaque pointer type] update test cases for explicit pointee types on global ↵David Blaikie2015-09-111-1/+1
| | | | | | aliases llvm-svn: 247380
* Delay emitting members of dllexport classes until the class is fully parsed ↵Hans Wennborg2015-08-151-1/+49
| | | | | | | | | | | | | | | | | (PR23542) 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
* [MS ABI] Stick constructor closures in an IR COMDAT groupDavid Majnemer2015-06-301-6/+6
| | | | | | | We no-longer stick linkonce_odr entities in COMDATs in the backend. Instead, we rely on the IR COMDAT mechanism. llvm-svn: 241117
* [MS Compatibility] Handle cleanups we create for a ctor closureDavid Majnemer2015-06-111-0/+16
| | | | | | This fixes PR23801. llvm-svn: 239503
* Enable DLL attribute propagation on explicit instantiation definitions (PR23770)Hans Wennborg2015-06-091-0/+5
| | | | | | | | 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
* MinGW: don't allow adding DLL attribute if template already has explicit ↵Hans Wennborg2015-06-091-0/+2
| | | | | | | | instantiation declaration This is a follow-up to r238266 which failed to take MinGW into account. llvm-svn: 239374
* Enable propagation of dll attributes to previously instantiated base class ↵Hans Wennborg2015-06-091-2/+17
| | | | | | | | | | | | | | | templates in some cases 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
* Get the dll storage class right for structors of classes exported/imported ↵Hans Wennborg2015-05-281-1/+2
| | | | | | | | | via explicit instantiation (PR23667) 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
* clang-cl: Handle dll attributes in explicit class template specialization ↵Hans Wennborg2015-05-271-0/+5
| | | | | | | | | | definitions (PR23667) 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
* __declspec is not a core Clang language extension. Instead, require ↵Aaron Ballman2015-05-261-4/+4
| | | | | | | -fms-extensions or -fborland to enable the language extension. 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
* [MS ABI] Implement thread-safe initialization using the MSVC 2015 ABIDavid Majnemer2015-05-071-4/+4
| | | | | | | | | 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
* Don't dllimport/export class members with internal linkage (PR23308)Hans Wennborg2015-04-221-0/+9
| | | | | | | | | | 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
* [opaque pointer types] Explicit non-pointer type for call expressionsDavid Blaikie2015-04-161-2/+2
| | | | | | (migration for recent LLVM change to textual IR for calls) llvm-svn: 235147
* MS ABI: Build C++ default argument exprs for exported template classesReid Kleckner2015-03-171-0/+9
| | | | | | This was an omission from r232229. llvm-svn: 232554
* MS ABI: Delay default constructor closure checking until the outermost class ↵Reid Kleckner2015-03-171-5/+21
| | | | | | | | | | | | | | | | | scope ends 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
* MS ABI: Generate default constructor closuresDavid Majnemer2015-03-131-0/+22
| | | | | | | | | | | | | | | | | | | | 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
* Test case updates for explicit type parameter to the gep operatorDavid Blaikie2015-03-131-1/+1
| | | | llvm-svn: 232187
* Don't dllexport inline methods when targeting MinGW.Hans Wennborg2015-02-191-16/+25
| | | | | | | | | MinGW neither imports nor exports such methods. The import bit was committed earlier, in r221154, and this takes care of the export part. This also partially fixes PR22591. llvm-svn: 229922
* MS ABI: Let guard variables be present in COMDATsDavid Majnemer2015-01-211-2/+2
| | | | | | A guard variable in a COMDAT'd function should also be in a COMDAT. llvm-svn: 226629
* Warn about dllexported explicit class template instantiation declarations ↵Hans Wennborg2015-01-151-0/+11
| | | | | | | | | | | | | | | (PR22035) Clang would previously become confused and crash here. It does not make a lot of sense to export these, so warning seems appropriate. MSVC will export some member functions for this kind of specializations, whereas MinGW ignores the dllexport-edness. The latter behaviour seems better. Differential Revision: http://reviews.llvm.org/D6984 llvm-svn: 226208
* [patch][pr19848] Produce explicit comdats in clang.Rafael Espindola2015-01-121-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | The llvm IR until recently had no support for comdats. This was a problem when targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of dead bits to remain on the executable (unless -ffunction-sections, -fdata-sections and --gc-sections were used). To fix the problem, llvm's codegen will just assume that any weak or linkonce that is not in an explicit comdat should be output in one with the same name as the global. This unfortunately breaks cases like pr19848 where a weak symbol is not xpected to be part of any comdat. Now that we have explicit comdats in the IR, we can finally get both cases right. This first patch just makes clang give explicit comdats to GlobalValues where t is allowed to. A followup patch to llvm will then stop implicitly producing comdats. llvm-svn: 225705
* Don't emit implicit template instantiations eagerly (PR21718)Hans Wennborg2015-01-101-0/+15
| | | | | | | | | | | | | | 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 llvm-svn: 225570
* Update for .ll syntax change.Rafael Espindola2015-01-061-1/+1
| | | | llvm-svn: 225303
* Disable warnings in this test.Rafael Espindola2015-01-051-4/+4
| | | | | | This makes it a lot easier to read the output from FileCheck when it fails. llvm-svn: 225190
* Don't dllimport inline functions when targeting MinGW (PR21366)Hans Wennborg2014-11-031-9/+11
| | | | | | | | | | | | 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
* MS ABI: Properly call global delete when invoking virtual destructorsDavid Majnemer2014-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: The Itanium ABI approach of using offset-to-top isn't possible with the MS ABI, it doesn't have that kind of information lying around. Instead, we do the following: - Call the virtual deleting destructor with the "don't delete the object flag" set. The virtual deleting destructor will return a pointer to 'this' adjusted to the most derived class. - Call the global delete using the adjusted 'this' pointer. Reviewers: rnk Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D5996 llvm-svn: 220993
* CodeGen: Don't form weak dllexport aliasesDavid Majnemer2014-10-241-2/+9
| | | | | | | | | | | The MS linker cannot do anything interesting with these, it doesn't make sense to emit them. This fixes PR21373. Differential Revision: http://reviews.llvm.org/D5986 llvm-svn: 220595
* Allow dllexport alias to base destructors.Rafael Espindola2014-10-071-5/+6
| | | | | | | | | | | We used to avoid these, but it looks like we did so just because we were not handling dllexport alias correctly. Dario Domizioli fixed that, so allow these aliases. Based on a patch by Dario Domizioli! llvm-svn: 219206
* MS ABI: Use '1' (instead of '0') relative scope discriminatorsDavid Majnemer2014-10-051-2/+2
| | | | | | | | 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
* Add another test for DLL attribute inheritance to partial specializationsHans Wennborg2014-08-231-0/+8
| | | | llvm-svn: 216337
* Fix CodeGenCXX/dllexport.cpp test. Somehow this slipped out of my previous ↵Hans Wennborg2014-08-231-1/+1
| | | | | | commit. llvm-svn: 216334
* MS ABI: Inherit DLL attributes to partial class template specializationsHans Wennborg2014-08-231-0/+8
| | | | llvm-svn: 216333
* MS ABI: Don't always instantiate all members of dllexported class templates ↵Hans Wennborg2014-08-211-4/+3
| | | | | | | | | | | | | | | | (PR20163) Normally we mark all members of exported classes referenced to get them emitted. However, MSVC doesn't do this for class templates that are implicitly specialized or just have an explicit instantiation declaration. For such specializations, the members are emitted when referenced. The exception is the case when the dllexport attribute is propagated from a base class to a base class template that doesn't have an explicit attribute: in this case all methods of the base class template do get instantiated. llvm-svn: 216145
* test/CodeGenCXX/dllexport.cpp: don't instantiate templates in USEMEMFUNC macroHans Wennborg2014-08-211-11/+11
| | | | | | | Use the derived class in the macro instead, to make it unambigous where the template is being instantiated. llvm-svn: 216142
* Mark C++ reference parameters as dereferenceableHal Finkel2014-07-181-3/+3
| | | | | | | | | | | | | | 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
* Fix clang tests to be compliant with LLVM IR aliasesDavid Majnemer2014-07-101-1/+1
| | | | | | | | | | Comdat IR references were mistakenly printed for aliases when they passed through the IR/AsmWriter code. This makes clang's tests not check for the existance of these wrongly printed comdat references. llvm-svn: 212733
* CodeGen: Cleanup MS ABI RTTI LLVM IRDavid Majnemer2014-07-071-1/+1
| | | | | | | | | | | | | The MS ABI RTTI emission code would choose names for IR types like %"MSRTTITypeDescriptor\02". This name is undesirable because it requires escaping; the underlying reason for this is that the name is unprintable. Fix this by naming it %rtti.TypeDescriptor2. While here, stop trying to do lookups in the LLVM Module's type table. Instead, store the IR types in MicrosoftCXXABI. Lookups by name aren't particularly fast. llvm-svn: 212439
* MS ABI: Reference MSVC RTTI from the VFTableDavid Majnemer2014-07-011-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pointer for a class's RTTI data comes right before the VFTable but has no name. To be properly compatible with this, we do the following: * Create a single GlobalVariable which holds the contents of the VFTable _and_ the pointer to the RTTI data. * Create a GlobalAlias, with appropriate linkage/visibility, that points just after the RTTI data pointer. This ensures that the VFTable symbol will always refer to VFTable data. * Create a Comdat with a "Largest" SelectionKind and stick the private GlobalVariable in it. By transitivity, the GlobalAlias will be a member of the Comdat group. Using "Largest" ensures that foreign definitions without an RTTI data pointer will _not_ be chosen in the final linked image. Whether or not we emit RTTI data depends on several things: * The -fno-rtti flag implies that we should never not emit a pointer to RTTI data before the VFTable. * __declspec(dllimport) brings in the VFTable from a remote DLL. Use an available_externally GlobalVariable to provide a local definition of the VFTable. This means that we won't have any available_externally definitions of things like complete object locators. This is acceptable because they are never directly referenced. To my knowledge, this completes the implementation of MSVC RTTI code generation. Further semantic work should be done to properly support /GR-. llvm-svn: 212125
* MS ABI: Propagate class-level DLL attributes to class template ↵Hans Wennborg2014-06-251-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+14
| | | | llvm-svn: 211648
* Inherit dll attributes to static localsHans Wennborg2014-06-181-0/+16
| | | | | | | | This makes us handle static locals in exported/imported functions correctly. Differential Revision: http://reviews.llvm.org/D4136 llvm-svn: 211173
* Defer codegen of inline method definitions to the end of current top level ↵Hans Wennborg2014-06-061-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | declaration We would previously fail to emit a definition of bar() for the following code: struct __declspec(dllexport) S { void foo() { t->bar(); } struct T { void bar() {} }; T *t; }; Note that foo() is an exported method, but bar() is not. However, foo() refers to bar() so we need to emit its definition. We would previously fail to realise that bar() is used. By deferring the method definitions until the end of the top level declaration, we can simply call EmitTopLevelDecl on them and rely on the usual mechanisms to decide whether the method should be emitted or not. Differential Revision: http://reviews.llvm.org/D4038 llvm-svn: 210356
* Itanium ABI: Update getAddrOfVTable to set the DLL storage class for vtablesHans Wennborg2014-06-021-0/+1
| | | | | | | | 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-0/+90
| | | | | | | | | | | | | | | | 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-19/+440
| | | | llvm-svn: 209596
* Emit used/dllexport inline method definitions in nested classes (PR19743, ↵Hans Wennborg2014-05-231-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR11170) The previous code that was supposed to handle this didn't work since parsing of inline method definitions is delayed to the end of the outer class definition. Thus, when HandleTagDeclDefinition() got called for the inner class, the inline functions in that class had not been parsed yet. Richard suggested that the way to do this is by handling inline method definitions through a new ASTConsumer callback. I really wanted to call ASTContext::DeclMustBeEmitted() instead of checking for attributes, but doing that causes us to compute linkage, and then we fail with "error: unsupported: typedef changes linkage of anonymous type, but linkage was already computed" on tests like this: (from SemaCXX/undefined-internal.cpp) :-/ namespace test7 { typedef struct { void bar(); void foo() { bar(); } } A; } Differential Revision: http://reviews.llvm.org/D3809 llvm-svn: 209549
* test/CodeGenCXX/dllexport.cpp: -O2 and -disable-llvm-optzns aren't neddedHans Wennborg2014-05-191-1/+1
| | | | | | | We only need them on the dllimport.cpp test to make sure that we emit code for available_externaly functions, and don't inline the IR. llvm-svn: 209145
* test/CodeGenCXX/dllexport.cpp: we already correctly emit b() even whenHans Wennborg2014-05-161-2/+1
| | | | | | | it's not used, because CodeGenModule::EmitGlobal consults ASTContext::DeclMustBeEmitted via CodeGenModule::MayDeferGeneration. llvm-svn: 208936
OpenPOWER on IntegriCloud