[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #28 from Jan Hubicka --- Author: hubicka Date: Thu Apr 13 08:04:52 2017 New Revision: 246899 URL: https://gcc.gnu.org/viewcvs?rev=246899&root=gcc&view=rev Log: PR lto/69953 * ipa-visibility.c (non_local_p): Fix typos. (localize_node): When localizing symbol in same comdat group, dissolve the group only when we know external symbols are going to be privatized. (function_and_variable_visibility): Do not localize DECL_EXTERNAL. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-visibility.c
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #27 from Jan Hubicka --- Created attachment 41176 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41176&action=edit Patch I am testing Hi, I am testing the attached patch. This is but subtle issue, but I hope that it works right now. For a first time we make difference what symbols in a comdat to privatize. In this case we only turn the construction vtable into comdat local and dissolve the whole comdat group incrementally.
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #26 from Jakub Jelinek --- (In reply to Jan Hubicka from comment #19) > > _ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE/10 > > (_ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE) @0x76816980 > > 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.
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #25 from Jakub Jelinek --- Why can't the middle-end/LTO handle comdat groups with some hidden and some non-hidden aliases? I don't see something inherently wrong on what the C++ FE is doing. Shouldn't we privatize the whole comdat group only if it has no exported symbols in it?
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #24 from Vincent Lefèvre --- Thanks for confirming. And indeed, I also get a failure with GCC 4.9.4, so that it is really different. For the reference, I've reported bug 78795.
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #23 from Markus Trippelsdorf --- (In reply to Vincent Lefèvre from comment #22) > I get the same kind of errors with "make check" for GMP 6.1.1 by using GCC > 6.2.1 and LTO (-flto=jobserve -fuse-linker-plugin), e.g. > > /tmp/ccZvS3pG.ltrans0.ltrans.o: In function `main': > :(.text.startup+0xc): undefined reference to `tests_start' > :(.text.startup+0x17): undefined reference to `mp_trace_base' > :(.text.startup+0x43): undefined reference to `__gmpn_random' > [...] > > but this is plain C, not C++. Is this the same bug? (I'm wondering because > this bug is attributed to the c++ component.) No, this must be a different issue.
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #22 from Vincent Lefèvre --- I get the same kind of errors with "make check" for GMP 6.1.1 by using GCC 6.2.1 and LTO (-flto=jobserve -fuse-linker-plugin), e.g. /tmp/ccZvS3pG.ltrans0.ltrans.o: In function `main': :(.text.startup+0xc): undefined reference to `tests_start' :(.text.startup+0x17): undefined reference to `mp_trace_base' :(.text.startup+0x43): undefined reference to `__gmpn_random' [...] but this is plain C, not C++. Is this the same bug? (I'm wondering because this bug is attributed to the c++ component.)
[Bug c++/69953] [5/6/7 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Richard Biener changed: What|Removed |Added Target Milestone|5.4 |5.5 --- Comment #21 from Richard Biener --- GCC 5.4 is being released, adjusting target milestone.
