On Mon, Aug 10, 2015 at 5:43 PM, Reid Kleckner <r...@google.com> wrote:
> On Mon, Aug 10, 2015 at 5:00 PM, Richard Smith <rich...@metafoo.co.uk> > wrote: > >> On Mon, Aug 10, 2015 at 12:39 PM, Reid Kleckner via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> Author: rnk >>> Date: Mon Aug 10 14:39:01 2015 >>> New Revision: 244488 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=244488&view=rev >>> Log: >>> [dllimport] A non-imported class with an imported key can't have a key >>> >>> Summary: >>> The vtable takes its DLL storage class from the class, not the key >>> function. When they disagree, the vtable won't be exported by the DLL >>> that defines the key function. The easiest way to ensure that importers >>> of the class emit their own vtable is to say that the class has no key >>> function. >>> >>> Reviewers: hans, majnemer >>> >>> Subscribers: cfe-commits >>> >>> Differential Revision: http://reviews.llvm.org/D11913 >>> >>> Modified: >>> cfe/trunk/lib/AST/RecordLayoutBuilder.cpp >>> cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp >>> >>> Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp >>> URL: >>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=244488&r1=244487&r2=244488&view=diff >>> >>> ============================================================================== >>> --- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original) >>> +++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Mon Aug 10 14:39:01 2015 >>> @@ -2008,6 +2008,12 @@ static const CXXMethodDecl *computeKeyFu >>> continue; >>> } >>> >>> + // If the key function is dllimport but the class isn't, then the >>> class has >>> + // no key function. The DLL that exports the key function won't >>> export the >>> + // vtable in this case. >>> + if (MD->hasAttr<DLLImportAttr>() && !RD->hasAttr<DLLImportAttr>()) >>> + return nullptr; >>> >> >> Does the same apply if the key function is DLLExport and the class is >> not? (Presumably this would just lead us to export a vtable that we don't >> need to, which is presumably harmless?) >> > > No, there's no issue with dllexport. If the key function is dllexport, > then it must be part of the same DLL as the current TU, and we can rely on > it to provide (potentially non-exported) vtable and RTTI symbols. > Even if a different compiler is used to compile the other TUs in this DLL? It seems to me that if the rule really is "the vtable takes its DLL storage class from the class, not the key function", then the TU with the key function need not actually provide a vtable symbol if the class is not dllexport but the key function is.
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
