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?
