[Bug lto/69394] [5.3] ICE when linking with lto

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On January 22, 2016 6:07:08 PM GMT+01:00, "daniel.f.starke at freenet dot de"
<gcc-bugzilla@gcc.gnu.org> wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394
>
>--- Comment #4 from Daniel Starke <daniel.f.starke at freenet dot de>
>---
>I see, but the output of the same GCC version should be the same
>regardless the
>host if the target is the same, right?
>I used the same source tree to build GCC 5.3.0 for x86_64-linux-gnu and
>for
>x86_64-w64-mingw32 host, both targeting x86_64-w64-mingw32.
>When I compile for example libsqlite3 on x86_64-w64-mingw32 with LTO
>enabled
>and try to link it on x86_64-linux-gnu, I get the ICE.
>If I compile libsqlite on x86_64-linux-gnu with the same options it
>works
>without an issue. So I guess the LTO format does not only depend on the
>used
>GCC version but also on the host. But this would be something I do not
>expect.

Not all host dependences have been sorted out indeed.

>Having the same GCC version (in all 3 places) and the same target
>should also
>give me the same result IMHO.

Desired but unfortunately not the case.

>Nevertheless, should I create a new PR for the problem with the
>non-executable
>result? I fail for example to run
>boost_1_54_0/libs/program_options/example/first.cpp on Windows, when I
>enable
>LTO on my Linux host.

Yes, but expect to need to track the issue down yourself...