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.
