https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #19 from Jan Hubicka <hubicka at ucw dot cz> ---
> _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?
Honza
