[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Marek Behun changed: What|Removed |Added CC||kabel at blackhole dot sk --- Comment #32 from Marek Behun --- (In reply to Steffen Hau from comment #31) Created PR70112
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394
--- Comment #31 from Steffen Hau steffen at hauihau dot de ---
Just a short update.
With LTO enabled, configure thinks I have a buggy GCC:
checking if gcc has a visibility bug with class-level attributes (GCC bug
26905)... yes
configure: WARNING: Your gcc is not -fvisibility=hidden safe. Disabling
visibility
I've then added -ffat-lto-objects to my ${C,CXX,Ld}FLAGS and the warning
disappeared.
The build failes at the same place, but instead of a segmentation fault I now
get a illegal instruction error:
/bin/sh: line 1: 10795 Illegal instruction SAL_USE_VCLPLUGIN=svp
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program
$I/program/gengal.bin -env:BRAND_BASE_DIR=file://$S/instdir
-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/drawinglayer/drawinglayer.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/package/source/xstor/xstor.component
file://$W/ComponentTarget/package/util/package2.component
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/svgio/svgio.component
file://$W/ComponentTarget/svx/util/svx.component
file://$W/ComponentTarget/svx/util/svxcore.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/unoxml/source/service/unoxml.component
-env:UNO_TYPES= file://$I/program/types/offapi.rdb
file://$I/ure/share/misc/types.rdb -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib
-env:LO_LIB_DIR=file://$I/program --build-tree --destdir
file://$S/extras/source/gallery --name arrows --path $W/Gallery/arrows
--filenames file://$RESPONSEFILE
/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72:
recipe for target
'/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done'
failed
make[1]: ***
[/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done]
Error 132
make[1]: *** Waiting for unfinished jobs
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394
Steffen Hau steffen at hauihau dot de changed:
What|Removed |Added
CC||steffen at hauihau dot de
--- Comment #30 from Steffen Hau steffen at hauihau dot de ---
Hey Jan,
I'm not able to successfully compile LO (4.4.2.2) with GCC 5.1.0. I'm getting
segmentation faults when gengal.bin is executed:
/bin/sh: line 1: 5682 Segmentation fault SAL_USE_VCLPLUGIN=svp
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$I/ure/lib:$I/program
$I/program/gengal.bin -env:BRAND_BASE_DIR=file://$S/instdir
-env:CONFIGURATION_LAYERS=xcsxcu:file://$I/share/registry
-env:UNO_SERVICES=file://$W/Rdb/ure/services.rdb
file://$W/ComponentTarget/comphelper/util/comphelp.component
file://$W/ComponentTarget/configmgr/source/configmgr.component
file://$W/ComponentTarget/drawinglayer/drawinglayer.component
file://$W/ComponentTarget/framework/util/fwk.component
file://$W/ComponentTarget/i18npool/util/i18npool.component
file://$W/ComponentTarget/package/source/xstor/xstor.component
file://$W/ComponentTarget/package/util/package2.component
file://$W/ComponentTarget/sax/source/expatwrap/expwrap.component
file://$W/ComponentTarget/sfx2/util/sfx.component
file://$W/ComponentTarget/svgio/svgio.component
file://$W/ComponentTarget/svx/util/svx.component
file://$W/ComponentTarget/svx/util/svxcore.component
file://$W/ComponentTarget/ucb/source/core/ucb1.component
file://$W/ComponentTarget/ucb/source/ucp/file/ucpfile1.component
file://$W/ComponentTarget/unoxml/source/service/unoxml.component
-env:UNO_TYPES= file://$I/program/types/offapi.rdb
file://$I/ure/share/misc/types.rdb -env:URE_INTERNAL_LIB_DIR=file://$I/ure/lib
-env:LO_LIB_DIR=file://$I/program --build-tree --destdir
file://$S/extras/source/gallery --name arrows --path $W/Gallery/arrows
--filenames file://$RESPONSEFILE
/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/solenv/gbuild/Gallery.mk:72:
recipe for target
'/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done'
failed
make[1]: ***
[/home/gentoo/tmp/portage/app-office/libreoffice-4.4.2.2/work/libreoffice-4.4.2.2/workdir/Gallery/arrows.done]
Error 139
make[1]: *** Waiting for unfinished jobs
Any ideas?
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 David Kredba nheghathivhistha at gmail dot com changed: What|Removed |Added CC||nheghathivhistha at gmail dot com --- Comment #28 from David Kredba nheghathivhistha at gmail dot com --- Gcc trunk revision 209488 built for me libreoffice 4.2.3.3 with -flto=4 -fuse-linker-plugin and resulting binaries works.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #29 from Jan Hubicka hubicka at gcc dot gnu.org --- Indeed, at the moment I see now important showstoppers for Libreoffice, only thing I need is ar/nm/ranlib wrapper on my path. I am closing this sort of open-ended PR until some problems reappears ;))
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #27 from Jan Hubicka hubicka at gcc dot gnu.org 2011-10-06 20:51:50 UTC --- OK, disabling Java gets me further now, but I now get an abort at: jh@evans:/abuild/jh/libreoffice/core more ./workdir/unxlngx6.pro/CppunitTest/comphelper_test.test.log terminate called after throwing an instance of 'CppUnit::DynamicLibraryManagerException' what(): Failed to load dynamic library: /abuild/jh/libreoffice/core/workdir/unxlngx6.pro/LinkTarget/CppunitTest/libtest_comphelper_test.so any idea?
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #24 from Michael Meeks michael.meeks at suse dot com 2011-09-23 08:33:17 UTC --- I can imagine that this sort of magic breaks with LTO. Is the solution as simple as using non-LTO version of libgcc3_uno.so? I will try to take a look how this is implemented. Great - so, we wouldn't loose much by having the bridge compiled without optimisation - it is ultimately used to map C++ - Java or python so all performance is already shot by that stage ;-) bridges/source/cpp_uno/gcc3_linux_intel/call.s bridges/source/cpp_uno/gcc3_linux_x86-64/call.s are the places to dig - unfortunately there is -far- too much cut/paste going on in here, though we've done some work to try to share more IIRC. These snippets are used by cpp2uno.cxx - to build trampolines cf. 'codeSnippet' - which (I hope) should work fine, and by uno2cpp.cxx to invoke things eg. 'uno2cpp.cxx's callVirtualMethod - which has some fun assembler in each case. Does that help ?
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #25 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-23 12:42:26 UTC --- New ICE with today's gcc and today's libreoffice: [ build PAG ] writer [ build LNK ] Executable/oosplash [ build LNK ] Library/libspl_unxlo.so [ build CMP ] desktop/unx/splash/splash [ build CMP ] desktop/unx/splash/splash [ build LNK ] Library/libevtattlo.so [ build CMP ] eventattacher/source/evtatt [ build CMP ] eventattacher/source/evtatt [ build LNK ] Library/libfileacc.so [ build CMP ] fileaccess/source/fileacc [ build CMP ] fileaccess/source/fileacc [ build LNK ] Library/libfrmlo.so [ build CMP ] forms/util/frm [ build CMP ] forms/util/frm [ build LNK ] Library/libforlo.so [ build CMP ] formula/util/for [ build CMP ] formula/util/for [ build LNK ] Library/libhwplo.so [ build CMP ] hwpfilter/source/hwp In file included from /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/solver/unxlngx6.pro/inc/cppu/unotype.hxx:3740:0, from :3330: /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx: In member function 'columnDropped': /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx:158:1: internal compiler error: in redirect_jump, at jump.c:1497 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [/var/tmp/portage/app-office/libreoffice--r1/temp/ccoLHzyy.ltrans2.ltrans.o] Error 1 make[2]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status make[1]: *** [/var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/workdir/unxlngx6.pro/LinkTarget/Library/libdbalo.so] Error 1 make[1]: *** Waiting for unfinished jobs...
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #26 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-23 15:52:02 UTC --- (In reply to comment #25) New ICE with today's gcc and today's libreoffice: /var/tmp/portage/app-office/libreoffice--r1/work/libreoffice-core-/dbaccess/source/core/api/table.cxx:158:1: internal compiler error: in redirect_jump, at jump.c:1497 This is now PR50496. I'm still reducing with delta.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #22 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-22 19:42:44 UTC --- (In reply to comment #20) For: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. This is new code, and shouldn't suffer lots of aliasing / compilation nasties I hope - it is also -fairly- self-standing and relatively simple. If we have a problem here - we have a real problem I think. I'd personally focus on that, it should (I hope) be easier. This problem is fixed in the current git version of LibreOffice. (I cannot reproduce it anymore, even with --with-max-jobs=4 and --with-num-cpus=4) How did you install though ? run a 'make dev-install' ? and then run install/program/soffice ? Yes. this: #6 0x77d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #7 0x718915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #8 0x71892dff in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #9 0x71893553 in cpp_vtable_call () from is altogether more hairy - we create at run-time C++ vtables packed with trampolines so we can intercept / model native C++ objects and interact with them via python etc. that would need some more intense debugging love I guess. and this one is the only remaining issue. Issue 3) from Comment 2 was a dup of PR50365 and was fixed by Jason recently.
Re: [Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
is altogether more hairy - we create at run-time C++ vtables packed with trampolines so we can intercept / model native C++ objects and interact with them via python etc. that would need some more intense debugging love I guess. and this one is the only remaining issue. That sounds promising. I can imagine that this sort of magic breaks with LTO. Is the solution as simple as using non-LTO version of libgcc3_uno.so? I will try to take a look how this is implemented. Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #23 from Jan Hubicka hubicka at ucw dot cz 2011-09-22 20:29:38 UTC --- is altogether more hairy - we create at run-time C++ vtables packed with trampolines so we can intercept / model native C++ objects and interact with them via python etc. that would need some more intense debugging love I guess. and this one is the only remaining issue. That sounds promising. I can imagine that this sort of magic breaks with LTO. Is the solution as simple as using non-LTO version of libgcc3_uno.so? I will try to take a look how this is implemented. Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #18 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-21 07:13:12 UTC --- (In reply to comment #17) I haven't found out exactly what libs are affected yet, because I've copied them in large chunks. Hmm, this is quite weird. I am not aware of any really important LTO related wrong code issues (and in general my experience is that LTO tends to ICE or produce missing symbols, not really produce wrong code that often). So my bet would be that libreoffice uses some tricks that breaks with LTO and we will need to idenitfy which one. If you could look into it, perhaps it would be interesting to identify smallest library that misoptimize and see what is happening with it. One common cause of problems is that -flto confuse the configure scripts. Some of configure tests are written in a way so LTO optimize the interesting part away and the test always pass. This usually leads to some link/parse errors but it also might break other things. Since you have both lto and non-lto builds, you could compare the config caches and see if they match? Yes, they are identical as far as I can tell. The problem seems to be that Libreoffice is ATM just too fragile when it comes to optimization flags. In other words, it will silently misoptimize in case of a non-supported -O flag. Quote from the Gentoo ebuild: # silent miscompiles; LO/OOo adds -O2/1/0 where appropriate filter-flags -O* And because the effect of LTO is to fully optimize the important parts of a program and use -Os for the rest, this could explain the crashes.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #19 from Jan Hubicka hubicka at ucw dot cz 2011-09-21 09:38:57 UTC --- # silent miscompiles; LO/OOo adds -O2/1/0 where appropriate filter-flags -O* And because the effect of LTO is to fully optimize the important parts of a program and use -Os for the rest, this could explain the crashes. GCC does not really bump up optimization levels and same heuristics is in limited degree applied w/o LTO as well. Debugging this seems quite important. Perhaps hacking -fno-strict-aliasing in addition to -flto at linktime could be first shot to get working binary?
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Michael Meeks michael.meeks at suse dot com changed: What|Removed |Added CC||michael.meeks at suse dot ||com --- Comment #20 from Michael Meeks michael.meeks at suse dot com 2011-09-21 11:03:30 UTC --- For: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. This is new code, and shouldn't suffer lots of aliasing / compilation nasties I hope - it is also -fairly- self-standing and relatively simple. If we have a problem here - we have a real problem I think. I'd personally focus on that, it should (I hope) be easier. How did you install though ? run a 'make dev-install' ? and then run install/program/soffice ? this: #6 0x77d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #7 0x718915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #8 0x71892dff in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #9 0x71893553 in cpp_vtable_call () from is altogether more hairy - we create at run-time C++ vtables packed with trampolines so we can intercept / model native C++ objects and interact with them via python etc. that would need some more intense debugging love I guess.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #21 from Jan Hubicka hubicka at ucw dot cz 2011-09-21 13:08:43 UTC --- is altogether more hairy - we create at run-time C++ vtables packed with trampolines so we can intercept / model native C++ objects and interact with them via python etc. that would need some more intense debugging love I guess. Hmm, this sounds scary. (I remember Kendy explaining me this years back when OOo was ported to x86_64.) More or less everything that is reachable externally ought to be annotated with used/externally_visible attributes or the assembly wrappers has to be visible at linktime. Is there some short overview of the machinery? (or could you explain it somehow? :) Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #16 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-20 15:39:41 UTC --- (In reply to comment #15) BTW since the exception seems to be thrown from libuno_cppuhelpergcc3.so.3 that sounds like there is some sort of gcc specific magic that has good chance to break with LTO, I would suggest to try to compile that dso w/o linktime (you only need to add -fno-use-linker-plugin -fno-lto) and hopefully we get past this issue? Unfortunately it's not that simple. It looks like several libraries in solver/unxlngx6.pro/lib are broken when they are build with LTO. What I've done is to copy working libraries from a non LTO build into solver/unxlngx6.pro/lib, until soffice.bin no longer crashes. But even cp /lib_working/*gcc* solver/unxlngx6.pro/lib isn't enough. You have to look at the back-traces to get an idea about what to copy next. And after copying many libs soffice.bin will no longer crash... I haven't found out exactly what libs are affected yet, because I've copied them in large chunks.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2011-09-20 22:19:38 UTC --- I haven't found out exactly what libs are affected yet, because I've copied them in large chunks. Hmm, this is quite weird. I am not aware of any really important LTO related wrong code issues (and in general my experience is that LTO tends to ICE or produce missing symbols, not really produce wrong code that often). So my bet would be that libreoffice uses some tricks that breaks with LTO and we will need to idenitfy which one. If you could look into it, perhaps it would be interesting to identify smallest library that misoptimize and see what is happening with it. One common cause of problems is that -flto confuse the configure scripts. Some of configure tests are written in a way so LTO optimize the interesting part away and the test always pass. This usually leads to some link/parse errors but it also might break other things. Since you have both lto and non-lto builds, you could compare the config caches and see if they match? Thanks! Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #15 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-19 16:09:23 UTC --- BTW since the exception seems to be thrown from libuno_cppuhelpergcc3.so.3 that sounds like there is some sort of gcc specific magic that has good chance to break with LTO, I would suggest to try to compile that dso w/o linktime (you only need to add -fno-use-linker-plugin -fno-lto) and hopefully we get past this issue? Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #14 from Jan Hubicka hubicka at ucw dot cz 2011-09-18 22:32:35 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #13 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-17 21:42:57 UTC --- (In reply to comment #12) (In reply to comment #11) With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed? It will build fine with LTO (and --without-java), but the resulting binary crashes during startup: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. I haven't looked deeper yet, but a non LTO build shows no problems at all. The above happened when I configured --with-max-jobs=4 and --with-num-cpus=4. With -with-max-jobs=1 and --with-num-cpus=4 I get a different crash on startup: Hmm, this is very weird. Since max-jobs affects nothing in GCC, it is probably some sort of build machinery problem. I guess it will be needed to debug what really happens here? Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #12 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-17 19:35:56 UTC --- (In reply to comment #11) With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed? It will build fine with LTO (and --without-java), but the resulting binary crashes during startup: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. I haven't looked deeper yet, but a non LTO build shows no problems at all.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #13 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-17 21:42:57 UTC --- (In reply to comment #12) (In reply to comment #11) With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed? It will build fine with LTO (and --without-java), but the resulting binary crashes during startup: terminate called after throwing an instance of 'com::sun::star::container::NoSuchElementException' It throws an exception in: xmlreader::XmlReader::XmlReader(rtl::OUString const) () from image/usr/ure/lib/libxmlreader.so. This happens in xmlreader/source/xmlreader.cxx. I haven't looked deeper yet, but a non LTO build shows no problems at all. The above happened when I configured --with-max-jobs=4 and --with-num-cpus=4. With -with-max-jobs=1 and --with-num-cpus=4 I get a different crash on startup: Program received signal SIGABRT, Aborted. 0x77db7695 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); #0 0x77db7695 in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x77db8b3d in __GI_abort () at abort.c:93 #2 0x77bc486d in _Unwind_SetGRValue (val=optimized out, index=optimized out, context=optimized out) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:253 #3 uw_update_context_1 (context=0x7fffbdc0, fs=0x7fffbc40) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1368 #4 0x77bc4b91 in uw_update_context (context=0x7fffbdc0, fs=0x7fffbc40) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1388 #5 0x77bc57cb in _Unwind_RaiseException (exc=0xe64150) at /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind.inc:122 #6 0x77d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6 #7 0x718915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #8 0x71892dff in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #9 0x71893553 in cpp_vtable_call () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #10 0x71895356 in privateSnippetExecutor () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/ure/lib/libgcc3_uno.so #11 0x779389f3 in cppu::throwException(com::sun::star::uno::Any const) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/program/../basis-link/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3 #12 0x769cd7ec in ucbhelper::cancelCommandExecution(com::sun::star::ucb::IOErrorCode, com::sun::star::uno::Sequencecom::sun::star::uno::Any const, com::sun::star::uno::Referencecom::sun::star::ucb::XCommandEnvironment const, rtl::OUString const, com::sun::star::uno::Referencecom::sun::star::ucb::XCommandProcessor const) () from /var/tmp/portage/app-office/libreoffice--r1/image/usr/program/../basis-link/program/libucbhelper4gcc3.so #13 0x in ?? ()
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 08:36:23 UTC --- With workaround I attached to PR50383 I can now build libsvx (and I did not try to get further, with bit of luck it will just work ;) W/o lto: evans:/abuild/jh/libreoffice/:[0]# size ./core/solver/unxlngx6.pro/lib/libsvxcorelo.so textdata bss dec hex filename 7628075 637648 10433 8276156 7e48bc ./core/solver/unxlngx6.pro/lib/libsvxcorelo.so With lto: evans:/abuild/jh/libreoffice/:[0]# size ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so textdata bss dec hex filename 6145323 635836 10384 6791543 67a177 ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so Not too bad.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 09:48:11 UTC --- Now it dies at /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../x86_64-unknown-linux-gnu/bin/ld: warning: hidden symbol 'typeinfo for SolarMutexResettableGuard' in /abuild/jh/libreoffice/core/workdir/unxlngx6.pro/CxxObject/sfx2/source/appl/app.o is referenced by DSO /abuild/jh/libreoffice/core/solver/unxlngx6.pro/lib/libvcllo.so lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /abuild/jh/trunk-install/bin/g++ returned 1 exit status I saw previously segfault in ipa-cp, so this might be same issue. Honza
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 09:59:47 UTC --- OK, the error is ipa-cp trying to fold ctor reference as: #1 0x005d2fee in fold_ctor_reference (type=0x753501f8, ctor=0x77ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880 2880 if (useless_type_conversion_p (type, TREE_TYPE (ctor)) (gdb) p debug_tree (type) pointer_type 0x753501f8 __vtbl_ptr_type type function_type 0x753502a0 type integer_type 0x77ec95e8 int public SI size integer_cst 0x77ecc240 constant 32 unit size integer_cst 0x77ecc260 constant 4 align 32 symtab 0 alias set 5 canonical type 0x77ec95e8 precision 32 min integer_cst 0x77ecc1e0 -2147483648 max integer_cst 0x77ecc200 2147483647 pointer_to_this pointer_type 0x77ed72a0 reference_to_this reference_type 0x71c7c930 QI size integer_cst 0x77ecc080 constant 8 unit size integer_cst 0x77ecc0a0 constant 1 align 8 symtab 0 alias set -1 canonical type 0x753502a0 pointer_to_this pointer_type 0x753501f8 __vtbl_ptr_type public unsigned DI size integer_cst 0x77eb9ec0 type integer_type 0x77ec90a8 bitsizetype constant 64 unit size integer_cst 0x77eb9ee0 type integer_type 0x77ec9000 sizetype constant 8 align 64 symtab 0 alias set -1 canonical type 0x753591f8 pointer_to_this pointer_type 0x75350150 $2 = void (gdb) p debug_tree (ctor) error_mark 0x77ec0b10 $3 = void (gdb) bt #0 useless_type_conversion_p (outer_type=0x753501f8, inner_type=0x66686e6973615f6e) at ../../gcc/tree-ssa.c:1292 #1 0x005d2fee in fold_ctor_reference (type=0x753501f8, ctor=0x77ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880 #2 0x005d3a6e in gimple_get_virt_method_for_binfo (token=960, known_binfo=optimized out) at ../../gcc/gimple-fold.c:3056 #3 0x00ae4cce in devirtualization_time_bonus (node=optimized out, known_csts=0x3622de0, known_binfos=0x3622d80) at ../../gcc/ipa-cp.c:1170 #4 0x00ae8b8c in estimate_local_effects (node=optimized out) at ../../gcc/ipa-cp.c:1401 #5 propagate_constants_topo (topo=optimized out) at ../../gcc/ipa-cp.c:1548 #6 ipcp_propagate_stage (topo=optimized out) at ../../gcc/ipa-cp.c:1631 #7 ipcp_driver () at ../../gcc/ipa-cp.c:2434 #8 0x006710a7 in execute_one_pass (pass=0x10916e0) at ../../gcc/passes.c:2063 #9 0x00671876 in execute_ipa_pass_list (pass=0x10916e0) at ../../gcc/passes.c:2430 #10 0x004ab3c4 in do_whole_program_analysis () at ../../gcc/lto/lto.c:2670 #11 0x004adf6d in lto_main () at ../../gcc/lto/lto.c:2796 #12 0x00704a32 in compile_file () at ../../gcc/toplev.c:548 #13 do_compile () at ../../gcc/toplev.c:1886 #14 toplev_main (argc=171, argv=0x11fe290) at ../../gcc/toplev.c:1962 #15 0x763efbc6 in __libc_start_main () from /lib64/libc.so.6 #16 0x004909e9 in _start () at ../sysdeps/x86_64/elf/start.S:113 Martin, is this optimized out binfo? I will try to reduce this mess, but it is huge, as you could expect
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 10:10:45 UTC --- OK, I guess the problem is that we don't stream initializer of extern variables. This leads to Martin's new devirtualization code to no longer be able to get the optimization done (and same way our folder). We should check for error_mark, but also get a testcase for missed optimization and probably start walking extern initializers when partitioning.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 10:14:09 UTC --- BTW we find only 1 devirtualization case on sfx: evans:/abuild/jh/libreoffice/:[0]# grep known target ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa* ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa.049i.inline:ipa-prop: Discovered an indirect call to a known target (transform/47233 - makeAny/46406), for stmt with uid 0 ./core/workdir/unxlngx6.pro/LinkTarget/Library/libsvxcorelo.so.wpa.049i.inline:ipa-prop: Discovered a virtual call to a known target (getStandardDate/24786 - ensureLoaded/57221), for stmt with uid 2
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 11:02:07 UTC --- PR50430 now tracks the svx2 issue.
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-16 14:45:07 UTC --- With fix I commited for PR50430 and the workaround for PR50383 my build dies on java modules. I believe it is the problem we run into with Michael on the opensuse conference and we made that module to be last (it is because on my setup sun java does not work and ibm java apparently breaks with current libreoffice). So perhaps this is all needed?
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-15 15:39:18 UTC --- Thanks a lot! is there any chance to get those fixes into official git so we don't need to cummulate local patches? :)
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-15 16:48:37 UTC --- (In reply to comment #3) Thanks a lot! is there any chance to get those fixes into official git so we don't need to cummulate local patches? :) It looks like some libreoffice developers are monitoring this meta-bug. Issue 2) is already fixed: http://cgit.freedesktop.org/libreoffice/core/commit/?id=87891c1c8bb82904fd68c523cb1aa11ddcfaaa3d
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Depends on||50383, 50381 Ever Confirmed|0 |1 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org 2011-09-14 09:55:19 UTC --- Currently libreoffice dies building svx at PR50383. Also there are couple of errors even with -fpermissive. Could someone look into that?
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-09-14 16:03:07 UTC --- Just successfully built libreoffice with todays gcc without LTO. I ran into three issues: 1) I use the following patch to include unistd.h in gcc/gthr-posix.h. This gets rid of many trivial errors. diff --git a/gcc/gthr-posix.h b/gcc/gthr-posix.h index b1d499d..3c155d0 100644 --- a/gcc/gthr-posix.h +++ b/gcc/gthr-posix.h @@ -39,6 +39,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #include pthread.h +#include unistd.h #if ((defined(_LIBOBJC) || defined(_LIBOBJC_WEAK)) \ || !defined(_GTHREAD_USE_MUTEX_TIMEDLOCK)) Revision 176335 deleted this include and the authors insist that this is the right thing to do... 2) There is an error in ./oox/inc/oox/helper/refmap.hxx: ../../inc/oox/helper/refmap.hxx:182:86: error: no matching function for call to 'find(oox::RefMapstd::pairshort int, rtl::OUString, oox::xls::DefinedName::key_type)' Fixed by following the note given in the warning that proceeds the error: ../../inc/oox/helper/refmap.hxx:182:86: warning: 'find' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] ../../inc/oox/helper/refmap.hxx:182:86: note: declarations in dependent base 'std::mapint, boost::shared_ptroox::xls::Connection, std::lessint, std::allocatorstd::pairconst int, boost::shared_ptroox::xls::Connection ' are not found by unqualified lookup ../../inc/oox/helper/refmap.hxx:182:86: note: use 'this-find' instead 3) There were three identical errors in /sc/source/ui/view/dbfunc.cxx (complaining that GetViewData() cannot be called without an object). Fixed by putting a this- before GetViewData() in lines 434, 463 and 473.
