http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49677
Summary: GCC 4.6.0 LTO files not compatible with GCC 4.6.1
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: edwinto...@gmail.com
Created attachment 24714
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24714
test.o
Using gcc 4.6.1 to link objects compiled with GCC 4.6.0 -flto produces this
error:
$ gcc test.o -flto -shared
lto1: error: bad value (generic) for -mtls-dialect= switch
lto-wrapper: /usr/bin/gcc returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
There is no -mtls-dialect=generic flag, (and there wasn't either).
Instead there is an -mtune=generic flag:
COLLECT_GCC_OPTIONS='-flto' '-shared' '-v' '-mtune=generic' '-march=x86-64'
I think 4.6.1 confuses -mtune and -mtls-dialect when loading 4.6.0 LTO objects.
Maybe the LTO version should be bumped to make these objects incompatible?
Fixing this compile error is possible if:
- make clean in all the projects that you link in
- ccache -C, ccache -c to delete all cached objects from previous version
It'd be better if GCC automatically detected that a certain LTO object file is
not compatible, and say which one it is.
In any case it'd be useful if there would be a -Wlto-mismatch, that would warn
if LTO objects were produced with different GCC versions (.comment section
should contain full version), or if the LTO objects and current compiler
version are different.
gcc -v output:
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-2'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-2)
I'm attaching the test.o file, because it the bug doesn't reproduce if I
compile it again from source with 4.6.1, only if I use the object file compiled
by 4.6.0.
