https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #19) > > _ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE/10 > > (_ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE) @0x7ffff6816980 > > Aha, this is an construction vtable and the privatization is done by: > /* Don't export construction vtables from shared libraries. Even on > targets that don't support hidden visibility, this tells > can_refer_decl_in_current_unit_p not to assume that it's safe to > access from a different compilation unit (bz 54314). */ > DECL_VISIBILITY (vtbl) = VISIBILITY_HIDDEN; > DECL_VISIBILITY_SPECIFIED (vtbl) = true; > > If I recall correctly the reason for that hunk is that C++ ABI does not > specify > if the construction vtable mangling. I wonder why those are part of the same > COMDAT group when the symbol itself is GNU extension. Won't things break if > one compiler produce COMDAT group definining the construction vtable while > other produce COMDAT group w/o and one w/o wins at static linking time? Please read PR54314, I think it explains it nicely. The hidden construction vtable symbols are meant to be emitted in comdat group XYZ and have all the uses only from the same comdat group XYZ, therefore it should not be an ABI issue how it is mangled (the Itanium C++ ABI mangling indeed does not seem to specify TC) etc. as long as the linker picks or drops comdat groups from one input object always as whole, never picks one section of comdat group XYZ from object a.o and another section of comdat group XYZ from object b.o.
