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