On 04/19/2018 02:56 PM, Stephan Bergmann wrote:
> Not sure how -Wclass-memaccess is relevant for LTO?
It's much easier to end up with an UBSAN that eventually causes a SEGFAULT.
That's my experience learned from Firefox.
Anyway, had cleaned up LO master the other day to compile with upcoming GC
Hi,
On Thu, Apr 19, 2018 at 01:38:52PM +0100, Michael Meeks
wrote:
> Would be great to have a configure.ac patch that checks for that option
> and uses it if it is present - it might also be nice to have some
> compile output from using that option - to file an easy-hack bug to go
> fix al
On 19/04/18 14:33, Martin Liška wrote:
I'm GCC developer with high focus on LTO. We are trying to use the -flto in
production.
I can confirm that current trunk looks fine. But before that I added
-flifetime-dse=1 to paper
over the issue. Please -Wclass-memaccess new warnings that will come with
Hi Martin,
On 19/04/18 13:33, Martin Liška wrote:
> I'm GCC developer with high focus on LTO. We are trying to
> use the -flto in production.
Nice =) Hopefully with some PGO goodness after that too ...
> I can confirm that current trunk looks fine. But before that I
> added -flifetime-ds
On 04/10/2018 09:32 AM, Tor Lillqvist wrote:
> The help message for the --enable-lto option says: "This is experimental work
> in progress that shouldn't be used unless you are working on it."
>
> Thus you have two choices: 1) Don't do that then, or 2) Debug and fix the
> problem.
>
> --tml
Hi
The help message for the --enable-lto option says: "This is experimental
work in progress that shouldn't be used unless you are working on it."
Thus you have two choices: 1) Don't do that then, or 2) Debug and fix the
problem.
--tml
___
LibreOffice mail
Following test-case is failing with --enable-lto:
[ 7806s] /bin/sh: line 1: 1652 Segmentation fault (core dumped) (
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/pro
gram":$W/UnpackedTarball/cppunit/src/cppunit/.libs MALLOC_CHECK_=2
MALLOC_PERTURB_=153 $W/LinkTarget/Exe
