summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX/dllimport.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Clang] Disable new PM for tests that use optimization level -O1, -O2 and -O3Petr Hosek2019-06-051-1/+1
| | | | | | | | | | Tests that use -O1, -O2 and -O3 would often produce different results with the new pass manager which makes these tests fail. Disable new PM explicitly for these tests. Differential Revision: https://reviews.llvm.org/D58375 llvm-svn: 362580
* Follow-up to r345699: Call CheckStaticLocalForDllExport later for templatesHans Wennborg2018-10-311-0/+10
| | | | | | | | Calling it too early might cause dllimport to get inherited onto the VarDecl before the initializer got attached. See the test case for an example where this broke things. llvm-svn: 345709
* [clang-cl] Inherit dllexport to static locals also in template ↵Hans Wennborg2018-10-311-0/+13
| | | | | | | | | | | | | | | | instantiations (PR39496) In the course of D51340, @takuto.ikuta discovered that Clang fails to put dllexport/import attributes on static locals during template instantiation. For regular functions, this happens in Sema::FinalizeDeclaration(), however for template instantiations we need to do something in or around TemplateDeclInstantiator::VisitVarDecl(). This patch does that, and extracts the code to a utility function. Differential Revision: https://reviews.llvm.org/D53870 llvm-svn: 345699
* Revert "[CodeGenCXX] Treat 'this' as noalias in constructors"Sean Fertile2018-10-151-1/+1
| | | | | | | This reverts commit https://reviews.llvm.org/rL344150 which causes MachineOutliner related failures on the ppc64le multistage buildbot. llvm-svn: 344526
* [CodeGenCXX] Treat 'this' as noalias in constructorsAnton Bikineev2018-10-101-1/+1
| | | | | | | | | This is currently a clang extension and a resolution of the defect report in the C++ Standard. Differential Revision: https://reviews.llvm.org/D46441 llvm-svn: 344150
* [MinGW] Don't mark external variables as DSO localMartin Storsjo2018-08-291-2/+2
| | | | | | | | | | | | Since MinGW supports automatically importing external variables from DLLs even without the DLLImport attribute, we shouldn't mark them as DSO local unless we actually know them to be local for sure. Keep marking thread local variables as DSO local. Differential Revision: https://reviews.llvm.org/D51382 llvm-svn: 340941
* Set dso_local when clearing dllimport.Rafael Espindola2018-03-291-0/+2
| | | | llvm-svn: 328801
* [MS] Don't escape MS C++ names with \01Reid Kleckner2018-03-161-151/+151
| | | | | | | It is not needed after LLVM r327734. Now it will be easier to copy-paste IR symbol names from Clang. llvm-svn: 327738
* Bring r325915 back.Rafael Espindola2018-02-231-90/+90
| | | | | | | | | | | | | | | 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
* Revert "Start setting dso_local for COFF."Rafael Espindola2018-02-231-90/+90
| | | | | | | | This reverts commit r325915. It will take some time to fix the failures on a windows host. llvm-svn: 325929
* Start setting dso_local for COFF.Rafael Espindola2018-02-231-90/+90
| | | | | | | | | 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
* Revert "Fix for PR32990"Reid Kleckner2017-12-211-2/+2
| | | | | | | | | | | | This reverts commit r321239. It broke the Chromium DLL build: [8834/50217] LINK(DLL) icui18n.dll icui18n.dll.lib icui18n.dll.pdb FAILED: icui18n.dll icui18n.dll.lib icui18n.dll.pdb zrule.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl icu_60::UnicodeString::`vbase destructor'(void)" (__imp_??_DUnicodeString@icu_60@@QEAAXXZ) llvm-svn: 321298
* Fix for PR32990Erich Keane2017-12-211-2/+2
| | | | | | | | | This fixes the bug in https://bugs.llvm.org/show_bug.cgi?id=32990. Patch By: zahiraam Differential Revision: https://reviews.llvm.org/D39063 llvm-svn: 321239
* MS ABI: Treat explicit instantiation definitions of dllimport function ↵Hans Wennborg2017-11-291-1/+10
| | | | | | | | | | | templates as explicit instantiation decls (PR35435) This matches MSVC's behaviour, and we already do it for class templates since r270897. Differential revision: https://reviews.llvm.org/D40621 llvm-svn: 319386
* [dllimport] Check for dtor references in functionsHans Wennborg2017-02-151-0/+7
| | | | | | | | | | | Destructor references are not modelled explicitly in the AST. This adds checks for destructor calls due to variable definitions and temporaries. If a dllimport function references a non-dllimport destructor, it must not be emitted available_externally, as the referenced destructor might live across the DLL boundary and isn't exported. llvm-svn: 295258
* [dllimport] Look through typedefs and arrays in HasNonDllImportDtorHans Wennborg2017-02-151-1/+1
| | | | | | | | The function is used to check whether a type is a class with non-dllimport destructor. It needs to look through typedefs and array types. llvm-svn: 295257
* Drop 'dllimport' when redeclaring inline function template without the ↵Hans Wennborg2017-02-011-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attribute (PR31695) For non-template dllimport functions, MSVC allows providing an inline definition without spelling out the attribute again. In the example below, f remains a dllimport function. __declspec(dllimport) int f(); inline int f() { return 42; } int useit() { return f(); } However, for a function template, not putting dllimport on the redeclaration causes it to be dropped. In the example below, f is not dllimport. template <typename> __declspec(dllimport) int f(); template <typename> inline int f() { return 42; } int useit() { return f<int>(); } This patch makes Clang match MSVC for the second example. MSVC does not warn about the attribute being dropped in the example above, but I think we should. (MSVC does warn if the inline keyword isn't used.) Differential Revision: https://reviews.llvm.org/D29152 llvm-svn: 293800
* Re-commit "Don't inline dllimport functions referencing non-imported methods"Hans Wennborg2017-01-231-0/+10
| | | | | | | This re-commits r292522 with the addition that it also handles calls through pointer to member functions without crashing. llvm-svn: 292856
* Revert "Don't inline dllimport functions referencing non-imported methods"Reid Kleckner2017-01-201-7/+0
| | | | | | | This reverts commit r292522. It appears to be causing crashes in builds using dllimport. llvm-svn: 292643
* Don't inline dllimport functions referencing non-imported methodsHans Wennborg2017-01-191-0/+7
| | | | | | | This is another follow-up to r246338. I had assumed methods were already handled by the AST visitor, but turns out they weren't. llvm-svn: 292522
* Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.Chandler Carruth2016-12-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* CodeGen: New vtable group representation: struct of vtable arrays.Peter Collingbourne2016-12-131-5/+5
| | | | | | | | | 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
* Also don't inline dllimport functions referring to non-dllimport constructors.Hans Wennborg2016-09-131-1/+5
| | | | | | | | The AST walker wasn't visiting CXXConstructExprs before. This is a follow-up to r281395. llvm-svn: 281413
* Try harder to not inline dllimport functions referencing non-dllimport functionsHans Wennborg2016-09-131-0/+7
| | | | | | | | 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
* [CodeGen] Treat imported static local variables as declarationsDavid Majnemer2016-07-111-2/+2
| | | | | | | Imported variables cannot really be definitions for the purposes of IR generation. llvm-svn: 275040
* Re-commit r270748 "clang-cl: Treat dllimport explicit template instantiation ↵Hans Wennborg2016-05-261-7/+42
| | | | | | | | | | definitions as declarations (PR27810, PR27811)" 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
* Revert r270748 "clang-cl: Treat dllimport explicit template instantiation ↵Hans Wennborg2016-05-251-42/+7
| | | | | | | | | definitions as declarations (PR27810, PR27811)" It seems to have broken the sanitizer-windows bot. Reverting while investigating. llvm-svn: 270754
* clang-cl: Treat dllimport explicit template instantiation definitions as ↵Hans Wennborg2016-05-251-7/+42
| | | | | | | | | | | declarations (PR27810, PR27811) 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
* [ms][dll] #26935 Defining a dllimport function should cause it to be exportedDenis Zobnin2016-05-251-2/+2
| | | | | | | | | | | | | | | | | | | 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
* Make sure CheckDestructor gets called on dllimported classes if the vtable ↵Hans Wennborg2016-04-131-0/+11
| | | | | | is used (PR27319) llvm-svn: 266242
* Add a few dllimport/dllexport tests. NFCReid Kleckner2016-03-021-0/+6
| | | | | | | | | | | | | | | | | | | | 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
* Revert "Revert r260388 "[MS ABI] Never reference dllimport'd vtables""David Majnemer2016-02-111-1/+1
| | | | | | | | | | | | | This reverts commit r260449. We would supress our emission of vftable definitions if we thought another translation unit would provide the definition because we saw an explicit instantiation declaration. This is not the case with dllimport, we want to synthesize a definition of the vftable regardless. This fixes PR26569. llvm-svn: 260548
* Revert r260388 "[MS ABI] Never reference dllimport'd vtables"Hans Wennborg2016-02-101-1/+1
| | | | | | | This caused the compiler to fail with "invalid linkage type for global declaration" (PR26569). llvm-svn: 260449
* [MS ABI] Never reference dllimport'd vtablesDavid Majnemer2016-02-101-1/+1
| | | | | | | | | | | | | Referencing a dllimported vtable is impossible in a constexpr constructor. It would be friendlier to C++ programmers if we synthesized a copy of the vftable which referenced imported virtual functions. This would let us initialize the object in a way which preserves both the intent to import functionality from another DLL while also making constexpr work. Differential Revision: http://reviews.llvm.org/D17061 llvm-svn: 260388
* Allow TLS vars in dllimport/export functions; only inline dllimport ↵Hans Wennborg2015-08-281-1/+41
| | | | | | | | | | | | | | | | | | | | | functions when safe (PR24593) This patch does two things: 1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase: 2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour. Differential Revision: http://reviews.llvm.org/D12422 llvm-svn: 246338
* Internal-linkage variables with constant-evaluatable initializers do not ↵Richard Smith2015-08-191-1/+1
| | | | | | need to be emitted. (Also reduces the set of variables that need to be eagerly deserialized when using PCH / modules.) llvm-svn: 245497
* -disable-llvm-optzns in one clang test.Evgeniy Stepanov2015-07-151-2/+2
| | | | | | | The intent is to test Clang codegen at -O1, and not the LLVM optimization pipeline. llvm-svn: 242315
* Enable DLL attribute propagation on explicit instantiation definitions (PR23770)Hans Wennborg2015-06-091-0/+6
| | | | | | | | 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/+1
| | | | | | | | 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/+18
| | | | | | | | | | | | | | | 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-2/+6
| | | | | | | | | 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/+12
| | | | | | | | | | 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-9/+9
| | | | | | | -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] Import move assignment operatorsDavid Majnemer2015-05-111-2/+4
| | | | | | | MSVC 2015 changed behavior from 2013; it imports move assignment operators. llvm-svn: 236966
* [MS ABI] Implement thread-safe initialization using the MSVC 2015 ABIDavid Majnemer2015-05-071-8/+8
| | | | | | | | | 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
* Update testcase to match r236539David Majnemer2015-05-051-1/+1
| | | | llvm-svn: 236542
* Don't dllexport inline methods when targeting MinGW.Hans Wennborg2015-02-191-5/+8
| | | | | | | | | 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
* [patch][pr19848] Produce explicit comdats in clang.Rafael Espindola2015-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Suppress clang warnings in a codegen test.Rafael Espindola2015-01-061-8/+8
| | | | | | | This makes the output of FileCheck way easier to read since this test hits many warnings. llvm-svn: 225322
* Don't dllimport inline functions when targeting MinGW (PR21366)Hans Wennborg2014-11-031-46/+57
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud