Bug 69953 - [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
Summary: [5/6 Regression] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 5.2.0
: P2 normal
Target Milestone: 5.5
Assignee: Martin Liška
URL:
Keywords: lto, wrong-code
Depends on:
Blocks:
 
Reported: 2016-02-25 08:56 UTC by john.frankish
Modified: 2017-09-07 10:13 UTC (History)
12 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.9.2, 7.1.0, 8.0
Known to fail: 5.1.0, 6.0
Last reconfirmed: 2016-02-25 00:00:00


Attachments
preprocessed gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc (564.34 KB, application/x-xz)
2016-02-26 06:14 UTC, john.frankish
Details
Patch I am testing (1.13 KB, patch)
2017-04-11 13:44 UTC, Jan Hubicka
Details | Diff
gparted build log (6.07 KB, text/plain)
2017-09-06 19:58 UTC, Andreas K. Huettel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description john.frankish 2016-02-25 08:56:22 UTC
I compiled libsigc++, glibmm, atkmm, cairomm and pangomm with "./configure --prefix=/usr/local --disable-static --localstatedir=/var" and no flags and gtkmm-2.24.4 with CXX="g++ -std=c++11"

gparted-0.25 then compiles without problems

If I repeat the same thing using CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe" ./configure --prefix=/usr/local --disable-static --localstatedir=/var

gparted-0.25 then fails to compile as below.

The same issue exists with gtkmm-3.16.0 and inkscape-0.91

libtool: link: g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe -Wall -std=gnu++11 -o gpartedbin Copy_Blocks.o DMRaid.o Device.o DialogFeatures.o DialogManageFlags.o Dialog_Base_Partition.o Dialog_Disklabel.o Dialog_FileSystem_Label.o Dialog_Partition_Copy.o Dialog_Partition_Info.o Dialog_Partition_Name.o Dialog_Partition_New.o Dialog_Partition_Resize_Move.o Dialog_Progress.o Dialog_Rescue_Data.o DrawingAreaVisualDisk.o FS_Info.o FileSystem.o Frame_Resizer_Base.o Frame_Resizer_Extended.o GParted_Core.o HBoxOperations.o LVM2_PV_Info.o Operation.o OperationChangeUUID.o OperationCheck.o OperationCopy.o OperationCreate.o OperationDelete.o OperationDetail.o OperationFormat.o OperationLabelFileSystem.o OperationNamePartition.o OperationResizeMove.o Partition.o PipeCapture.o Proc_Partitions_Info.o SWRaid_Info.o TreeView_Detail.o Utils.o Win_GParted.o btrfs.o exfat.o ext2.o f2fs.o fat16.o hfs.o hfsplus.o jfs.o linux_swap.o lvm2_pv.o main.o nilfs2.o ntfs.o reiser4.o reiserfs.o ufs.o xfs.o -pthread  -L/usr/local/lib /usr/local/lib/libgthread-2.0.so /usr/local/lib/libgtkmm-2.4.so /usr/local/lib/libatkmm-1.6.so /usr/local/lib/libgdkmm-2.4.so /usr/local/lib/libgiomm-2.4.so /usr/local/lib/libpangomm-1.4.so /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libcairomm-1.0.so /usr/local/lib/libsigc-2.0.so /usr/local/lib/libgtk-x11-2.0.so /usr/local/lib/libgdk-x11-2.0.so /usr/local/lib/libpangocairo-1.0.so /usr/local/lib/libatk-1.0.so /usr/local/lib/libcairo.so /usr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libpangoft2-1.0.so /usr/local/lib/libpango-1.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libfontconfig.so /usr/local/lib/libfreetype.so /usr/local/lib/libparted-fs-resize.so /usr/local/lib/libparted.so -ldl /usr/lib/libuuid.so -pthread
/tmp/cczCWt7F.ltrans0.ltrans.o: In function `Gtk::TreeViewColumn::TreeViewColumn<Glib::ustring>(Glib::ustring const&, Gtk::TreeModelColumn<Glib::ustring> const&) [clone .lto_priv.613]':
<artificial>:(.text+0x692): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0x6ce): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0x6e7): undefined reference to `vtable for Gtk::TreeViewColumn'
<artificial>:(.text+0x6ef): undefined reference to `vtable for Gtk::TreeViewColumn'
<artificial>:(.text+0x721): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0x733): undefined reference to `VTT for Gtk::TreeViewColumn'
/tmp/cczCWt7F.ltrans0.ltrans.o: In function `Gtk::TreeViewColumn::TreeViewColumn<Glib::RefPtr<Gdk::Pixbuf> >(Glib::ustring const&, Gtk::TreeModelColumn<Glib::RefPtr<Gdk::Pixbuf> > const&) [clone .lto_priv.612]':
<artificial>:(.text+0x2ca8): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0x2ce4): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0x2cfd): undefined reference to `vtable for Gtk::TreeViewColumn'
<artificial>:(.text+0x2d05): undefined reference to `vtable for Gtk::TreeViewColumn'
<artificial>:(.text+0x2d3c): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0x2d4e): undefined reference to `VTT for Gtk::TreeViewColumn'
/tmp/cczCWt7F.ltrans28.ltrans.o: In function `GParted::DialogManageFlags::DialogManageFlags(GParted::Partition const&, std::map<Glib::ustring, bool, std::less<Glib::ustring>, std::allocator<std::pair<Glib::ustring const, bool> > >) [clone .constprop.455]':
<artificial>:(.text+0xf1f): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0xf65): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0xf7f): undefined reference to `vtable for Gtk::TreeViewColumn'
<artificial>:(.text+0xf88): undefined reference to `vtable for Gtk::TreeViewColumn'
<artificial>:(.text+0xfd5): undefined reference to `VTT for Gtk::TreeViewColumn'
<artificial>:(.text+0xfec): undefined reference to `VTT for Gtk::TreeViewColumn'
collect2: error: ld returned 1 exit status
Makefile:512: recipe for target 'gpartedbin' failed
make[2]: *** [gpartedbin] Error 1
make[2]: Leaving directory '/usr/src/gparted-0.25.0/src'
Makefile:580: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/src/gparted-0.25.0'
Makefile:434: recipe for target 'all' failed
make: *** [all] Error 2
[reply] [−] Comment 1
Comment 1 Markus Trippelsdorf 2016-02-25 10:02:02 UTC
Find out which source file implements Gtk::TreeViewColumn.
Attach the preprocessed file of that compilation unit here.
Comment 2 Richard Biener 2016-02-25 10:08:08 UTC
Also try GCC 5.3 (or a recent snapshot from the branch).
Comment 3 Martin Liška 2016-02-25 14:03:20 UTC
Hello.

I've just tried to build latest inkscape (gparted) with latest GCC, and no problem seen for following configurations:

inkscape:
-Os -flto=9
-flto -fuse-linker-plugin -mtune=generic -Os -pipe

gparted:
-Os -flto=9
-flto -fuse-linker-plugin -mtune=generic -Os -pipe

Martin
Comment 4 john.frankish 2016-02-26 06:14:12 UTC
Created attachment 37800 [details]
preprocessed gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc

I'm not too sure what I'm doing here, but Gtk::TreeViewColumn seems to be implemented by gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc

Outout attached from:

$ g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe -std=c++11 -E gtkmm-3.16.0/gtk/gtkmm/treeviewcolumn.cc -I/usr/local/include/glibmm-2.4 -I/usr/local/lib/glibmm-2.4/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/sigc++-2.0 -I/usr/local/lib/sigc++-2.0/include -I/usr/local/include/gtkmm-3.0 -I/usr/local/lib/gtkmm-3.0/include -I/usr/local/lib/gdkmm-3.0/include -I/usr/local/lib/pangomm-1.4/include -I/usr/local/include/gtk-3.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/cairo -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0 -I/usr/local/include/pangomm-1.4 -I/usr/local/include/cairomm-1.0 -I/usr/local/include/freetype2 -I/usr/local/include/atkmm-1.6 -I/usr/local/include/gdkmm-3.0 -I/usr/local/include/giomm-2.4
Comment 5 Markus Trippelsdorf 2016-02-26 08:28:34 UTC
markus@x4 tmp % g++ -flto -c -O2 -std=c++11 treeviewcolumn.i && nm treeviewcolumn.o | grep _ZTVN3Gtk14TreeViewColumnE
00000000 W _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % g++ -c -O2 -std=c++11 treeviewcolumn.i && nm treeviewcolumn.o | grep _ZTVN3Gtk14TreeViewColumnE
0000000000000000 V _ZTVN3Gtk14TreeViewColumnE

In the resulting lib:

x4 ~ # nm /usr/lib64/libgtkmm-2.4.so.1.1.0 | grep _ZTVN3Gtk14TreeViewColumnE
00000000003408e0 d _ZTVN3Gtk14TreeViewColumnE.lto_priv.729
(without lto:)
x4 ~ # nm /tmp/libgtkmm-2.4.so.1.1.0 | grep _ZTVN3Gtk14TreeViewColumnE
00000000004331a0 V _ZTVN3Gtk14TreeViewColumnE
Comment 6 Markus Trippelsdorf 2016-02-26 08:37:26 UTC
markus@x4 tmp % g++ -flto -fPIC -DPIC -shared -nostdlib treeviewcolumn.i && nm ./a.out | grep _ZTVN3Gtk14TreeViewColumnE

000000000000b4d8 d _ZTVN3Gtk14TreeViewColumnE.lto_priv.2
markus@x4 tmp % g++  -fPIC -DPIC -shared -nostdlib treeviewcolumn.i && nm ./a.out | grep _ZTVN3Gtk14TreeViewColumnE

000000000000d648 V _ZTVN3Gtk14TreeViewColumnE
Comment 7 john.frankish 2016-02-26 08:38:01 UTC
err, OK - excuse my ignorance, but that does that imply?
Comment 8 Markus Trippelsdorf 2016-02-26 08:43:01 UTC
(In reply to john.frankish from comment #7)
> err, OK - excuse my ignorance, but that does that imply?

It it the reason for your link failure.
Now the question is, if the compiler is right to make the symbol local with LTO?
Comment 9 Markus Trippelsdorf 2016-02-26 10:51:20 UTC
clang makes the symbol external for both lto and non-lto:

000000000000d5f0 D _ZTVN3Gtk14TreeViewColumnE

Reducing...
Comment 10 Markus Trippelsdorf 2016-02-26 13:04:57 UTC
markus@x4 tmp % cat foo.ii
namespace Glib {
class ObjectBase {
protected:
  virtual ~ObjectBase();
};
class A : virtual public ObjectBase {};
class B : virtual public ObjectBase {};
}
namespace Gtk {
class C : Glib::A {};
class D : public Glib::B {};
class TreeViewColumn : C, D {
  ~TreeViewColumn();
};
TreeViewColumn::~TreeViewColumn() {}
}

markus@x4 tmp % g++ -Os -flto -fPIC -shared -nostdlib -std=c++11 foo.ii && nm ./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"

00000000000026a8 d _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % g++ -Os -fPIC -shared -nostdlib -std=c++11 foo.ii && nm ./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"

00000000000025c8 V _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % g++ -O2 -fPIC -shared -nostdlib -std=c++11 foo.ii && nm ./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"

00000000000013a8 V _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % clang++ -O2 -fPIC -shared -nostdlib -std=c++11 foo.ii && nm ./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"

0000000000002900 D _ZTVN3Gtk14TreeViewColumnE
markus@x4 tmp % clang++ -flto -O2 -fPIC -shared -nostdlib -std=c++11 foo.ii && nm ./a.out | grep "_ZTVN3Gtk14TreeViewColumnE"

0000000000002450 D _ZTVN3Gtk14TreeViewColumnE
Comment 11 Markus Trippelsdorf 2016-02-26 15:25:05 UTC
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() {}
}
Comment 12 john.frankish 2016-03-01 07:56:31 UTC
Is there any hope of a patch to fix this?
Comment 13 john.frankish 2016-03-01 09:04:11 UTC
'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)
Comment 14 Jan Hubicka 2016-03-01 09:08:57 UTC
Will take a look
Comment 15 john.frankish 2016-03-01 09:15:36 UTC
Ah - clang works when I replace ld with ld.gold renamed to ld.
Comment 16 john.frankish 2016-03-08 05:34:05 UTC
Any news on a possible patch?
Comment 17 john.frankish 2016-03-08 10:30:26 UTC
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:

  CXXLD    inkscape
widgets/gradient-selector.o: In function `Gtk::TreeViewColumn::TreeViewColumn<int>(Glib::ustring const&, Gtk::TreeModelColumn<int> 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._ZN3Gtk14TreeViewColumnC1IN4Glib6RefPtrIN3Gdk6PixbufEEEEERKNS2_7ustringERKNS_15TreeModelColumnIT_EE[_ZN3Gtk14TreeViewColumnC5IN4Glib6RefPtrIN3Gdk6PixbufEEEEERKNS2_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
Comment 18 Jan Hubicka 2016-03-19 17:58:11 UTC
The problem is that the symbol shares comdat group with
_ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE/10 (_ZTCN3Gtk14TreeViewColumnE0_N4Glib6ObjectE) @0x7ffff6816980
  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) @0x7ffff6816000       
  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.
Comment 19 Jan Hubicka 2016-03-19 19:44:08 UTC
> _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
Comment 20 Richard Biener 2016-03-23 10:51:12 UTC
FE issue manifesting as wrong-code with LTO.
Comment 21 Richard Biener 2016-06-03 10:07:45 UTC
GCC 5.4 is being released, adjusting target milestone.
Comment 22 Vincent Lefèvre 2016-12-13 15:01:46 UTC
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':
<artificial>:(.text.startup+0xc): undefined reference to `tests_start'
<artificial>:(.text.startup+0x17): undefined reference to `mp_trace_base'
<artificial>:(.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.)
Comment 23 Markus Trippelsdorf 2016-12-13 15:12:37 UTC
(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':
> <artificial>:(.text.startup+0xc): undefined reference to `tests_start'
> <artificial>:(.text.startup+0x17): undefined reference to `mp_trace_base'
> <artificial>:(.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.
Comment 24 Vincent Lefèvre 2016-12-13 15:26:27 UTC
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.
Comment 25 Jakub Jelinek 2017-04-01 09:59:14 UTC
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?
Comment 26 Jakub Jelinek 2017-04-06 06:13:19 UTC
(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.
Comment 27 Jan Hubicka 2017-04-11 13:44:03 UTC
Created attachment 41176 [details]
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.
Comment 28 Jan Hubicka 2017-04-13 08:05:24 UTC
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
Comment 29 Jakub Jelinek 2017-04-13 11:17:14 UTC
Fixed on the trunk so far, thanks Honza.
Comment 30 DB 2017-06-01 18:06:41 UTC
I get similar issues when compiling glibmm-2.4 from git with g++ 6.3 and LTO, but not without LTO: undefined references to destructors for Glib::RefPtr<Gtk::TreeModel> and Glib::RefPtr<Gtk::Application>.

Can this be related, or should I open another bug?
Comment 31 DB 2017-06-01 18:07:52 UTC
Uh, sorry. I mean when compiling my own application against glibmm and gtkmm, using LTO on my app (only).
Comment 32 Martin Liška 2017-06-22 11:16:48 UTC
Author: marxin
Date: Thu Jun 22 11:16:16 2017
New Revision: 249514

URL: https://gcc.gnu.org/viewcvs?rev=249514&root=gcc&view=rev
Log:
Backport r246899

2017-06-22  Martin Liska  <mliska@suse.cz>

	Backport from mainline
	2017-04-12  Jan Hubicka  <hubicka@ucw.cz>

	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:
    branches/gcc-6-branch/gcc/ChangeLog
    branches/gcc-6-branch/gcc/ipa-visibility.c
Comment 33 Martin Liška 2017-06-22 11:44:12 UTC
Fixed on GCC 6.x, no plan to backport back to GCC 5, closing as resolved.
Comment 34 Andreas K. Huettel 2017-08-31 20:42:10 UTC
According to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 *not* fixed for gcc-6.
Comment 35 Andreas K. Huettel 2017-08-31 20:43:15 UTC
Oops sorry, that should have been:

According to https://bugs.gentoo.org/show_bug.cgi?id=629342 *not* fixed for gcc-6.
Comment 36 Martin Liška 2017-09-01 07:43:51 UTC
Please provide one more test-case that still fails and I will take a look. Feel free to reopen it.
Comment 37 Andreas K. Huettel 2017-09-06 19:58:59 UTC
Created attachment 42140 [details]
gparted build log

Here's the build log from my Gentoo colleague.

If you need more, please tell me precisely what - I dont have that much experience reporting here yet. Can't reopen the bug either.
Comment 38 Martin Liška 2017-09-07 10:13:24 UTC
So downloading the package and testing that with problematic 6.3 does not reproduce. Can you please verify you have really GCC 6.4? If so, would it be possible to create a virtual machine or a Docker image which I can replay and thus reproduce?