I compile the files attached with this command-line: "g++ ltotest.cpp int.cpp -oltotest -s -O3 -flto" and get the following error: "lto1.exe: internal compiler error: invalid resolution in the resolution file" configured with: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ../../mingw-src/gcc-4.7-20111001/configure \ --host=i686-pc-mingw32 \ --build=i686-pc-mingw32 \ --target=i686-pc-mingw32 \ --prefix=/mingw-sjlj-x86 \ --with-arch=i686 \ --with-tune=generic \ --enable-languages=c,c++,lto,objc,obj-c++,fortran \ --with-host-libstdcxx=-lstdc++ \ --disable-shared \ --enable-static \ --enable-cxx-flags='-fno-function-sections -fno-data-sections' \ --enable-libstdcxx-time=yes \ --enable-libgomp \ --enable-lto \ --enable-graphite \ --enable-cloog-backend=isl \ --enable-checking=release \ --enable-fully-dynamic-string \ --enable-threads=posix \ --disable-libstdcxx-pch \ --enable-libstdcxx-debug \ --enable-sjlj-exceptions \ --disable-debug \ --disable-bootstrap \ --disable-multilib \ --disable-rpath \ --disable-win32-registry \ --disable-nls \ --disable-werror \ --disable-symvers \ --with-gmp=/mingw-libs \ --with-mpfr=/mingw-libs \ --with-mpc=/mingw-libs \ --with-ppl=/mingw-libs \ --with-cloog=/mingw-libs \ --with-libiconv-prefix=/mingw-libs \ Thread model: posix gcc version 4.7.0 20111001 (experimental)
Created attachment 25416 [details] LTO test sources
Please attach the resolution file (you can obtain it by adding -v -save-temps to the command-line, the file is the one mentioned as argument to the -fresolution= command-line argument to lto1.exe) What binutils version are you using? I suspect a mismatch between binutils/gcc here.
Created attachment 26229 [details] sources + temp files + logs
I think the (null)'s are odd at least. 2 ltotest.o 15 1068 a2f6b3c8 (null) PREVAILING_DEF 1010 a2f6b3c8 (null) RESOLVED_EXEC 1082 a2f6b3c8 (null) RESOLVED_EXEC 1086 a2f6b3c8 (null) RESOLVED_EXEC 1093 a2f6b3c8 (null) RESOLVED_EXEC ... First of all, the symbol name should come 4th, not 3rd - the resolution belongs there. This means you are very likely using a bogus lto-plugin shared object that does not match the GCC version you are using. Though I do not remeber any version that dumped things in the order I see in your attached file. So, please check which file is specified as -plugin argument to the linker (it should be visible in the -v dump) and remove that and/or replace it with a current version. Hmm. We use fprintf (f, "%u %llx %s %s\n", (unsigned int) slot, symtab->aux[j].id, lto_resolution_str[resolution], symtab->syms[j].name); maybe that falls foul of some special Window-ism (aka unportable %llx?). Kai?
I don't have other GCC versions or lto-pugins on my computer. Here is a fragment of code from gcc-4.6.2-release: fprintf (f, "%u %x %s %s\n", (unsigned int) slot, symtab->aux[j].id, lto_resolution_str[resolution], symtab->syms[j].name); This one is the same fragment from gcc-4.6.3-branch: fprintf (f, "%u %x %s %s\n", (unsigned int) slot, symtab->aux[j].id, lto_resolution_str[resolution], symtab->syms[j].name); And this one is the same fragment from gcc-trunk: fprintf (f, "%u %llx %s %s\n", (unsigned int) slot, symtab->aux[j].id, lto_resolution_str[resolution], symtab->syms[j].name);
Replacing "%llx" to "%I64x" solves the problem. http://msdn.microsoft.com/en-us/library/3b2e7499(v=vs.80).aspx Thanks, niXman.
This is a host side issue really. Anyways we should use uin64_t with PRIx64 so it is more portable.
Could you please tell which file you are speaking of, where to apply your fix from comment #6? This bug does not occur on my system. i compiled gcc-4.7.0-20120217 on mingw32 on Windows 7 - 64bit for target=avr. But my compiler will generate the bug when run on 32-bit Windows. If i apply your hack from comment #6, will my compiler-lto then be usable on 32-bit but not on 64bit?
lto-plugin/lto-plugin.c http://gcc.gnu.org/viewcvs/trunk/lto-plugin/lto-plugin.c?view=markup line 363.
Yes, not all msvcrt versions are supporting %ll width modifier. Modern versions of it (as 64-bit versions) are supporting it, but older (and still pretty common on 32-bit OSes) don't. Therefore it is for native Windows apps more compatible to use here instead %I64. As Andrew mentioned we might should use here instead PRIx64 for output of 64-bit integer-scalars. Any patch in this direction would be welcome for me.
Author: ktietz Date: Wed Feb 22 10:19:22 2012 New Revision: 184462 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184462 Log: PR lto/50616 * lto-plugin.c (PRI_LL): New macro. (dump_symtab): Use PRI_LL instead of ll in print. (process_symtab): Use PRI_LL instead of ll in scan. Modified: trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c
Fixed.