[Bug lto/50394] New: [meta-bug] Issues with building libreoffice with LTO

[Bug lto/50394] New: [meta-bug] Issues with building libreoffice with LTO

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394

             Bug #: 50394
           Summary: [meta-bug] Issues with building libreoffice with LTO
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hubicka@gcc.gnu.org


This is tracking PR for libreoffice issues, similar to PR45375

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[hubicka at gcc dot gnu.org]

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

[markus at trippelsdorf dot de]

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::RefMap<std::pair<short 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::map<int, boost::shared_ptr<oox::xls::Connection>, std::less<int>,
std::allocator<std::pair<const int, boost::shared_ptr<oox::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.

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[hubicka at gcc dot gnu.org]

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

[markus at trippelsdorf dot de]

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

[hubicka at gcc dot gnu.org]

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
   text    data     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
   text    data     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

[hubicka at gcc dot gnu.org]

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

[hubicka at gcc dot gnu.org]

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  0x00000000005d2fee in fold_ctor_reference (type=0x7ffff53501f8,
ctor=0x7ffff7ec0b10, 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 0x7ffff53501f8 __vtbl_ptr_type
    type <function_type 0x7ffff53502a0
        type <integer_type 0x7ffff7ec95e8 int public SI
            size <integer_cst 0x7ffff7ecc240 constant 32>
            unit size <integer_cst 0x7ffff7ecc260 constant 4>
            align 32 symtab 0 alias set 5 canonical type 0x7ffff7ec95e8
precision 32 min <integer_cst 0x7ffff7ecc1e0 -2147483648> max <integer_cst
0x7ffff7ecc200 2147483647>
            pointer_to_this <pointer_type 0x7ffff7ed72a0> reference_to_this
<reference_type 0x7ffff1c7c930>>
        QI
        size <integer_cst 0x7ffff7ecc080 constant 8>
        unit size <integer_cst 0x7ffff7ecc0a0 constant 1>
        align 8 symtab 0 alias set -1 canonical type 0x7ffff53502a0
        pointer_to_this <pointer_type 0x7ffff53501f8 __vtbl_ptr_type>>
    public unsigned DI
    size <integer_cst 0x7ffff7eb9ec0 type <integer_type 0x7ffff7ec90a8
bitsizetype> constant 64>
    unit size <integer_cst 0x7ffff7eb9ee0 type <integer_type 0x7ffff7ec9000
sizetype> constant 8>
    align 64 symtab 0 alias set -1 canonical type 0x7ffff53591f8
    pointer_to_this <pointer_type 0x7ffff5350150>>
$2 = void
(gdb) p debug_tree (ctor)
 <error_mark 0x7ffff7ec0b10>
$3 = void
(gdb) bt
#0  useless_type_conversion_p (outer_type=0x7ffff53501f8,
inner_type=0x66686e6973615f6e) at ../../gcc/tree-ssa.c:1292
#1  0x00000000005d2fee in fold_ctor_reference (type=0x7ffff53501f8,
ctor=0x7ffff7ec0b10, offset=1088, size=64) at ../../gcc/gimple-fold.c:2880
#2  0x00000000005d3a6e in gimple_get_virt_method_for_binfo (token=960,
known_binfo=<optimized out>) at ../../gcc/gimple-fold.c:3056
#3  0x0000000000ae4cce in devirtualization_time_bonus (node=<optimized out>,
known_csts=0x3622de0, known_binfos=0x3622d80) at ../../gcc/ipa-cp.c:1170
#4  0x0000000000ae8b8c 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  0x00000000006710a7 in execute_one_pass (pass=0x10916e0) at
../../gcc/passes.c:2063
#9  0x0000000000671876 in execute_ipa_pass_list (pass=0x10916e0) at
../../gcc/passes.c:2430
#10 0x00000000004ab3c4 in do_whole_program_analysis () at
../../gcc/lto/lto.c:2670
#11 0x00000000004adf6d in lto_main () at ../../gcc/lto/lto.c:2796
#12 0x0000000000704a32 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 0x00007ffff63efbc6 in __libc_start_main () from /lib64/libc.so.6
#16 0x00000000004909e9 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

[hubicka at gcc dot gnu.org]

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

[hubicka at gcc dot gnu.org]

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

[hubicka at gcc dot gnu.org]

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

[hubicka at gcc dot gnu.org]

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

[markus at trippelsdorf dot de]

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

[markus at trippelsdorf dot de]

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.
0x00007ffff7db7695 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
64        return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
#0  0x00007ffff7db7695 in __GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff7db8b3d in __GI_abort () at abort.c:93
#2  0x00007ffff7bc486d 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=0x7fffffffbdc0, fs=0x7fffffffbc40) at
/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1368
#4  0x00007ffff7bc4b91 in uw_update_context (context=0x7fffffffbdc0,
fs=0x7fffffffbc40) at
/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libgcc/../gcc/unwind-dw2.c:1388
#5  0x00007ffff7bc57cb 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  0x00007ffff7d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#7  0x00007ffff18915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) ()
from
/var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so
#8  0x00007ffff1892dff 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-9999-r1/image/usr/ure/lib/libgcc3_uno.so
#9  0x00007ffff1893553 in cpp_vtable_call () from
/var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so
#10 0x00007ffff1895356 in privateSnippetExecutor () from
/var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so
#11 0x00007ffff79389f3 in cppu::throwException(com::sun::star::uno::Any const&)
() from
/var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/program/../basis-link/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3
#12 0x00007ffff69cd7ec in
ucbhelper::cancelCommandExecution(com::sun::star::ucb::IOErrorCode,
com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&,
com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment>
const&, rtl::OUString const&,
com::sun::star::uno::Reference<com::sun::star::ucb::XCommandProcessor> const&)
() from
/var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/program/../basis-link/program/libucbhelper4gcc3.so
#13 0x0000000000000000 in ?? ()

[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO

[hubicka at ucw dot cz]

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

[hubicka at gcc dot gnu.org]

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

[markus at trippelsdorf dot de]

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

[hubicka at ucw dot cz]

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

[markus at trippelsdorf dot de]

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

[hubicka at ucw dot cz]

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

[michael.meeks at suse dot com]

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  0x00007ffff7d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6
#7  0x00007ffff18915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) ()
from
/var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so
#8  0x00007ffff1892dff 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-9999-r1/image/usr/ure/lib/libgcc3_uno.so
#9  0x00007ffff1893553 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

[hubicka at ucw dot cz]

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

[markus at trippelsdorf dot de]

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  0x00007ffff7d0d741 in __cxa_throw () from /usr/lib64/libstdc++.so.6
> #7  0x00007ffff18915c8 in gcc3::raiseException(_uno_Any*, _uno_Mapping*) ()
> from
> /var/tmp/portage/app-office/libreoffice-9999-r1/image/usr/ure/lib/libgcc3_uno.so
> #8  0x00007ffff1892dff 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-9999-r1/image/usr/ure/lib/libgcc3_uno.so
> #9  0x00007ffff1893553 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

[Jan Hubicka]

> > 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

[hubicka at ucw dot cz]

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

[michael.meeks at suse dot com]

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

[markus at trippelsdorf dot de]

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-9999-r1/work/libreoffice-core-9999/solver/unxlngx6.pro/inc/cppu/unotype.hxx:3740:0,
                 from :3330:
/var/tmp/portage/app-office/libreoffice-9999-r1/work/libreoffice-core-9999/dbaccess/source/core/api/table.cxx:
In member function 'columnDropped':
/var/tmp/portage/app-office/libreoffice-9999-r1/work/libreoffice-core-9999/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-9999-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-9999-r1/work/libreoffice-core-9999/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

[markus at trippelsdorf dot de]

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-9999-r1/work/libreoffice-core-9999/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

[hubicka at gcc dot gnu.org]

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

[nheghathivhistha at gmail dot com]

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

[hubicka at gcc dot gnu.org]

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

[steffen at hauihau dot de]

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

[steffen at hauihau dot de]

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....