Revision 193777 ICEs with lto1.exe: internal compiler error: cannot read LTO decls from <the object file> when linking with -flto on i686-w64-mingw32. This happens for all inputs, even for "int main() { return 0; }" or "" (that is, an empty file). >> gcc -v Using built-in specs. COLLECT_GCC=C:\devel\mingw\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/devel/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.8.0/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../gcc-4.8-svn/configure --disable-nls --build=i686-w64-mingw32 --disable-multilib --enable-languages=c,c++,lto --disable-win32-registry --enable-openmp --enable-libgomp --enable-graphite --enable-cxx-flags='-fno-function-sections -fno-data-sections' --enable-threads=posix --disable-symvers --enable-fully-dynamic-string --disable-libstdcxx-pch --with-arch=i686 --with-tune=generic --enable-checking=release --disable-werror --disable-sjlj-exceptions --prefix=/c/builds/gcc/toolchain/out --with-gmp=/c/builds/gcc/prerequisites/out --with-mpfr=/c/builds/gcc/prerequisites/out --with-mpc=/c/builds/gcc/prerequisites/out --with-isl=/c/builds/gcc/prerequisites/out --with-cloog=/c/builds/gcc/prerequisites/out --with-libiconv-prefix=/c/builds/gcc/prerequisites/out --with-host-libstdcxx=-lstdc++ --enable-cloog-backend=isl Thread model: posix gcc version 4.8.0 20121124 (experimental) (GCC)
Forgot to mention: 4.7.2 - works 4.8.0 r193777 - fails
Are you sure that you do not somehow pull in LTO objects from older releases? Needs someone with access to $target to debug.
(In reply to comment #2) > Are you sure that you do not somehow pull in LTO objects from older releases? Yes, happens even with -nostdlib, even on builds where I'm absolutely sure there's no way an old LTO object could sneak in.
(In reply to comment #3) > (In reply to comment #2) > > Are you sure that you do not somehow pull in LTO objects from older releases? > > Yes, happens even with -nostdlib, even on builds where I'm absolutely sure > there's no way an old LTO object could sneak in. I can't reproduce that. btw how are you doing linker-tests without specifying object-code and libraries? Nevertheless I assume that runtime is build with older-version of gcc. It is a bit sad that LTO doesn't tell that version is outdated. I've tested it with gcc version from 15th of January 2012 and it works flawless. But I have rebuild my runtime with new version. That is recommented to do. I would suggest to close that bug as WORKSFORME
After retesting it, I close it as works for me.
Oh right. Works for me too. I should've tested it more thoroughly first. Sorry for bothering you guys.
Reopening. The build that worked for me was a cross compiler on x86_64-unknown-linux-gnu host. Native compiler on i686-mingw32 host still fails when trying to use LTO. So either I'm doing something terribly wrong (I think I'm not, I built everything from scratch with the very same compiler version this time), or there *is* a bug.
I can confirm that this bug is present for GCC 4.8 dated 20121221, which is available here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/gcc-4.8-unstable/i686-w64-mingw32-gcc-4.8-unstable-win32_rubenvb.7z/download I get: lto1.exe: internal compiler error: cannot read LTO decls from R:\temp\ccgzHybZ.o Please submit a full bug report, with preprocessed source if appropriate. See <mingw-w64-public@lists.sourceforge.net> for instructions. lto-wrapper: g++ returned 1 exit status m:/development/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.8.0/../../../../i686-w64-mingw32/bin/ld.exe: lto-wrapper failed collect2.exe: error: ld returned 1 exit status
Somebody needs to debug this.
Well, I re-tried to reproduce this issue with current 4.8 gcc version (native). As before, I can't reproduce that issue. Anyway I don't get what report was actual doing differently as I did, so I will keep this bug open. Nevertheless we had recently some changes to lto, which are affecting mingw targets, so it might be worth that report are retrying to reproduce. Please make sure that you aren't mixing objects with LTO-infomration of different versions.
Revision 196313 appears to work.