rnk added a comment. In https://reviews.llvm.org/D43184#1005534, @mstorsjo wrote:
> In https://reviews.llvm.org/D43184#1005281, @smeenai wrote: > > > > > > A related observation on the topic of this: There's a subtle difference > between what both GCC and MSVC does here, compared to clang. The case with a > single variable works the same in all of them, but if you have a struct with > many initialized elements, GCC and MSVC will initialize as many as possible > of them statically, and only fill in the dllimport ones via a dynamic > initializer. clang, on the other hand, will not initialize anything > statically at all if it emits a dynamic initializer. The Qt bug is interesting, but I think we're doing the right thing here. C++ doesn't define any semantics for partially initialized objects. It's unclear if clang or GCC's way of doing things is better or not. With clang, you get to put the global in .bss, so it's not clear what makes for bigger code size. In https://reviews.llvm.org/D43184#1008003, @mstorsjo wrote: > In https://reviews.llvm.org/D43184#1005258, @rnk wrote: > > > Do you think we should do something like local vftables for itanium > > instead? Can we assume all methods in the vtable will be exported by the > > DLL exporting the class? > > > Will this actually ever be needed for other vtables than > cxxabi::class_type_info and the others from > ItaniumRTTIBuilder::BuildVTablePointer? In what other cases are the vtables > referred to from a statically initialized global? And for these vtables - > there's no declaration of them at all within most translation units, so > that'd require hardcoding all the content of these vtables in > ItaniumRTTIBuilder. Here's a case where a local vtable would help: struct __declspec(dllimport) A { virtual void a(); }; struct __declspec(dllimport) B { virtual void b(); }; struct __declspec(dllimport) C : A, B { void a() override; void b() override; }; constexpr C c; I'm suggesting we can make a DSO local copy of _ZTV1C, so that we can refer to it from `c`. It's OK if the vtable refers to the imported thunks, since the address of virtual methods isn't user visible. Either that, or we need to make something like this change here, right? Repository: rC Clang https://reviews.llvm.org/D43184 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
