Behaviour of GCC with flto probably bug

Behaviour of GCC with flto probably bug

[Erotavlas_turbo]

Hi,

I noticed the following behaviour of GCC. If I compile with gcc 4.8.1 (Ubuntu 
12.04 64 bit) a code made up of several source files and I use the flag -flto 
to produce a set of object files. Then if I link in another system with older 
version of gcc (4.7.x or 4.6.x) and without -flto all works well. Otherwise, if 
I use -flto I get this error: 

lto1: fatal error: LTO_tags out of range: Range is 0 to 361, value is 15872
compilation terminated.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

So is not allowed to compile with one version and flto options and link with 
an old version?

Then if I try to link in another machine with Debian 7 64 bit and gcc-4.8.1 
with this command:

g++ -O3 -march=native -mtune=native -flto /home/user/lib.a -L/usr/local/lib -
llibrary1 -lpthread -lz -o dva

I get lto1: internal compiler error: in lto_tag_to_tree_code, at lto-streamer.
h:924
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
lto-wrapper: g++ returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

Is it a bug?

Thank you

Re: Behaviour of GCC with flto probably bug

[Florian Weimer]

On 02/01/2014 05:17 PM, Erotavlas_turbo@libero.it wrote:

> So is not allowed to compile with one version and flto options and link with
> an old version?

Yes, this is documented:

      The current implementation of LTO makes no attempt to generate
      bytecode that is portable between different types of hosts.  The
      bytecode files are versioned and there is a strict version check,
      so bytecode files generated in one version of GCC will not work
      with an older/newer version of GCC.

It seems that the version check does not actually work, which is a bug 
(please report it in Bugzilla).  But LTO is really sensitive to compiler 
and library versions, so this will not solve your original problem.

-- 
Florian Weimer / Red Hat Product Security Team