[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 #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 21 Jan 2016, daniel.f.starke at freenet dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394
> 
> --- Comment #2 from Daniel Starke <daniel.f.starke at freenet dot de> ---
> I have tested the same with gcc 4.9.3 to make clear whether this is a
> regression or not. Sadly I was not able to build the libstdc++ with -flto.
> Compiling the same program as before did not result in a ICE but did produce a
> binary which was not exatuable on the target platform.
> Next I build gcc 5.3.0 again and all used libraries with that compiler. Before
> I did use some libraries I generated with gcc 5.3.0 on the target platform, not
> on Linux. So I suspect that the output of the same gcc differs on Windows and
> Linux even though the same target is built.
> The result was the same as with gcc 4.9.3. The produced binary was not
> executable.
> For information, this was the backtrace:
> #0  0x0000000000635ef2 in std::type_info::operator== (this=this@entry=0x6cffe8
> <typeinfo for windows_file_codecvt>, arg=...)
>     at ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/tinfo.cc:46
> #1  0x00000000005bf0f4 in __cxxabiv1::__si_class_type_info::__do_dyncast
> (this=0x6cffe8 <typeinfo for windows_file_codecvt>, src2dst=0, 
>     access_path=__cxxabiv1::__class_type_info::__contained_public,
> dst_type=0x0, obj_ptr=0x3790a0, 
>     src_type=0x6e5280 <typeinfo for std::locale::facet>, src_ptr=0x3790a0,
> result=...)
>     at
> ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/si_class_type_info.cc:52
> #2  0x00000000006a6fdb in __cxxabiv1::__dynamic_cast (src_ptr=0x3790a0,
> src_type=src_type@entry=0x6e5280 <typeinfo for std::locale::facet>, 
>     dst_type=dst_type@entry=0x0, src2dst=src2dst@entry=0) at
> ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/dyncast.cc:72
> #3  0x00000000006a12b0 in std::use_facet<std::codecvt<wchar_t, char, int> >
> (__loc=...)
>     at
> /new-gcc/bin64-64/gcc-5.3.0/x86_64-w64-mingw32/libstdc++-v3/include/bits/locale_classes.tcc:139
> #4  0x00000000004dfce5 in boost::filesystem::path::codecvt() ()
> #5  0xffffffffffffffff in ?? ()
> #6  0x000000000067b727 in std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::basic_string(char const*,
> std::allocator<char> const&) [clone .isra.1100] ()
> #7  0x000000000022fde0 in ?? ()
> #8  0x00000000004f4ed9 in atexit ()
> #9  0x00000000006b52a0 in (anonymous namespace)::__new_handler ()
> #10 0x0000000000000003 in ?? ()
> #11 0x00000000007050f0 in vtable for
> boost::detail::sp_counted_impl_p<boost::spirit::qi::tst<char, char> > ()
> #12 0x00000000006ab266 in
> _GLOBAL__sub_I__ZN3pcf6parser6spirit18getInnerInfoStringB5cxx11ERKN5boost6spirit4infoE
> ()
> #13 0x0000000000000000 in ?? ()
> 
> Using the compiled libraries from before gives me the following ICE:
> lto1: internal compiler error: bytecode stream: expected tag bit_field_ref
> instead of error_mark
> Replacing for example the libsqlite3 from the build with the compiler in
> question gives me the following ICE:
> In member function 'do_real_get':
> lto1: internal compiler error: bytecode stream: expected tag real_type instead
> of error_mark
> 
> Is there no version tag within the LTO code which detects if the format is
> compatible in an early stage?

There is, but it's manually bumped and we do so only for each new major
release.  That is, we fail to be careful to detect all possible ways
the format could change (because that's not always obvious).

ICEs of the above kind strongly hint at incompatible binaries though.
I suppose we could enhance the error reporting here (maybe even stream
a stricter "version", like the SVN revision or some such and take
a mismatch at the above ICE point as a hint of an incompatibility).

What will have caused an incompatibility from 5.2 to 5.3 is

2015-10-06  Richard Biener  <rguenther@suse.de>

        Backport from mainline
...
        2015-09-24  Richard Biener  <rguenther@suse.de>

        PR lto/67699
        * lto-cgraph.c (compute_ltrans_boundary): Do not stream
        abstract origins.

for example.  There are various MPX related changes that look
suspicious but those should only make a difference if you use MPX.

That said, computing a checksum of the LTO streamer related bits
might be a possibility (if we accept spurious incompatibility messages).