[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #19 from Jan Hubicka --- > _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? Honza
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Jan Hubicka changed: What|Removed |Added CC||jason at redhat dot com --- Comment #18 from Jan Hubicka --- The problem is that the symbol shares comdat group with _ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE/10 (_ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE) @0x76816980 Type: variable definition analyzed Visibility: forced_by_abi externally_visible prevailing_def_ironly public weak comdat comdat_group:_ZTVN3Gtk14TreeViewColumnE one_only visibility_specified visibility:hidden virtual artificial Same comdat group as: _ZTCN3Gtk14TreeViewColumnE0_1C/9 References: _ZTIN4Glib6ObjectE/31 (addr) Referring: _ZTTN3Gtk14TreeViewColumnE/8 (addr) Read from file: t.o Availability: available Varpool flags: initialized read-only const-value-known the symbol itself is: _ZTVN3Gtk14TreeViewColumnE/7 (_ZTVN3Gtk14TreeViewColumnE) @0x76816000 Type: variable definition analyzed Visibility: forced_by_abi externally_visible prevailing_def_ironly public weak comdat comdat_group:_ZTVN3Gtk14TreeViewColumnE one_only virtual artificial Same comdat group as: _ZTCN3Gtk14TreeViewColumnE8_N4Glib1BE/12 References: _ZTIN3Gtk14TreeViewColumnE/23 (addr)_ZN3Gtk14TreeViewColumnD1Ev/5 (addr)_ZN3Gtk14TreeViewColumnD0Ev/6 (addr)_ZTIN3Gtk14TreeViewColumnE/23 (addr) Referring: _ZN3Gtk14TreeViewColumnD1Ev/5 (addr)_ZTTN3Gtk14TreeViewColumnE/8 (addr)_ZTTN3Gtk14TreeViewColumnE/8 (addr)_ZN3Gtk14TreeViewColumnD0Ev/6 (addr) Read from file: /tmp/cc2mBAHW.o Availability: not-ready Varpool flags: initialized read-only const-value-known The problem is that one is hidden and other is exported. The hidden one will make us to privatize the whole comdat group. Jason, is this intentional? What is the reason for hidding some symbols and keeping other exported? If it is intentional I wonder what to do - I suppose we can privatize the hidden symbols and take them out of the comdat groups as long as we know they are not accessed by the non-IR code. Otherwise we need to keep whole comdat group untouched? This is bit tricky, but of course not that hard to implement.
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.4
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #17 from john.frankish at outlook dot com --- This is perhaps worse than I thought - I went back and re-compiled libsigc++, glibmm, atkmm, cairomm, pangomm and gtkmm using gcc-5.2.0 without "-flto -fuse-linker-plugin". I then compiled inkscape-0.91 again and it fails at the final linking stage in a similar fashion as that when I compiled all of the above using lto: CXXLDinkscape widgets/gradient-selector.o: In function `Gtk::TreeViewColumn::TreeViewColumn(Glib::ustring const&, Gtk::TreeModelColumn const&)': gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x29): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x65): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x81): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x91): undefined reference to `vtable for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x9a): undefined reference to `vtable for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0xa8): undefined reference to `vtable for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0xda): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0xef): undefined reference to `VTT for Gtk::TreeViewColumn' gradient-selector.cpp:(.text._ZN3Gtk14TreeViewColumnC1IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IiEERKN4Glib7ustringERKNS_15TreeModelColumnIT_EE]+0x104): undefined reference to `VTT for Gtk::TreeViewColumn' ... input.cpp:(.text._ZN3Gtk14TreeViewColumnC1IN4Glib6RefPtrIN3Gdk6PixbufERKNS2_7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IN4Glib6RefPtrIN3Gdk6PixbufERKNS2_7ustringERKNS_15TreeModelColumnIT_EE]+0x104): undefined reference to `VTT for Gtk::TreeViewColumn' collect2: error: ld returned 1 exit status Makefile:6891: recipe for target 'inkscape' failed make[3]: *** [inkscape] Error 1 make[3]: Leaving directory '/usr/src/inkscape-0.91/src' Makefile:5048: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/usr/src/inkscape-0.91/src' Makefile:1401: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/usr/src/inkscape-0.91' Makefile:1096: recipe for target 'all' failed make: *** [all] Error 2
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #16 from john.frankish at outlook dot com --- Any news on a possible patch?
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #15 from john.frankish at outlook dot com --- Ah - clang works when I replace ld with ld.gold renamed to ld.
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED CC||hubicka at gcc dot gnu.org --- Comment #14 from Jan Hubicka --- Will take a look
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #13 from john.frankish at outlook dot com --- 'Kind of digressing, but when I try with clang, I get this: $ clang++ -v -flto -O2 -fPIC -shared -nostdlib -std=c++11 foo.ii clang version 3.7.0 (tags/RELEASE_370/final) Target: x86_64-unknown-linux-gnu Thread model: posix Found candidate GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0 Selected GCC installation: /usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0 Candidate multilib: .;@m64 Selected multilib: .;@m64 "/usr/local/bin/clang" -cc1 -triple x86_64-unknown-linux-gnu -flto -emit-llvm-bc -disable-free -disable-llvm-verifier -main-file-name clang.ii -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.25.1 -momit-leaf-frame-pointer -v -dwarf-column-info -resource-dir /usr/local/bin/../lib/clang/3.7.0 -O2 -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /usr/src -ferror-limit 19 -fmessage-length 134 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /tmp/clang-920273.o -x c++-cpp-output clang.ii clang -cc1 version 3.7.0 based upon LLVM 3.7.0 default target x86_64-unknown-linux-gnu #include "..." search starts here: End of search list. "/usr/local/bin/ld" --eh-frame-hdr -m elf_x86_64 -shared -o a.out -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0 -L/lib/../lib64 -L/usr/local/bin/../lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../.. -L/usr/local/bin/../lib -L/lib -L/usr/lib -plugin /usr/local/bin/../lib/LLVMgold.so -plugin-opt=mcpu=x86-64 /tmp/clang-920273.o /tmp/clang-920273.o: file not recognized: File format not recognized clang: error: linker command failed with exit code 1 (use -v to see invocation)
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #12 from john.frankish at outlook dot com --- Is there any hope of a patch to fix this?
[Bug lto/69953] [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
Markus Trippelsdorf changed:
What|Removed |Added
Known to work||4.9.2
Summary|Using lto causes|[5/6 Regression] Using lto
|gtkmm/gparted and |causes gtkmm/gparted and
|gtkmm/inkscape compile to |gtkmm/inkscape compile to
|fail|fail
Known to fail||5.1.0, 6.0
--- Comment #11 from Markus Trippelsdorf ---
Here's another testcase that only produces a local symbol for all -O levels
with -flto:
namespace Glib {
class A {};
class Object : virtual A {
protected:
~Object();
};
class B : virtual A {};
}
class C : Glib::Object {};
namespace Gtk {
class D : Glib::B {};
class TreeViewColumn : C, D {
virtual ~TreeViewColumn();
};
TreeViewColumn::~TreeViewColumn() {}
}
