>From http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02148.html
I can see some issues here with output portability that should be
addressed for objects with LTO information to be portable between hosts.
1. There are some structures lto_*header that include 16-bit or 32-bit
integer fields (plus an enum). It appears that the byte sequences for
these headers get written out verbatim eithout regard for endianness
issues, and reading in a file written on a host with the other endianness
will result in an assertion failure. Regarding the appropriateness of an
assertion failure here see my comments on error handling, but it should
not be hard to write out each field explicitly with defined endianness
that does not depend on the endianness of the host. There are other
places writing out individual integers like this (at least
write_global_references, lto_output_decl_state_refs, write_symbol_vec)
that will also need fixing.
2. The storing of values in bitpacks may depend on the number of bits in
various types. I haven't looked at whether how the integers of size
BITS_PER_BITPACK_WORD = HOST_BITS_PER_WIDE_INT are then written out to see
whether the host endianness is also relevant there; if it is, that should
be addressed.
(a) The cases where HOST_BITS_PER_WIDE_INT bits are stored in a bitpack
would most simply be addressed by making LTO imply 64-bit (exactly)
HOST_WIDE_INT for all hosts and targets. (I'd be happy for
HOST_WIDE_INT to be made 64-bit everywhere whether or not LTO is
enabled, in the interests of avoiding host-dependency in code
generation, but making it so for LTO may be less controversial.)
(b) We can reasonably assume HOST_BITS_PER_INT to be 32, and
HOST_BITS_PER_SHORT to be 16, for all hosts, but a static assertion that
these are so if building LTO would ensure no problems arise with it
building but producing bad objects on unusual hosts. Likewise for the
case using sizeof (unsigned) * 8.
(c) REAL_CSTs, writing out HOST_BITS_PER_LONG bits, may take more care.
The obvious way is to encode them in target format before writing out,
then decode when reading in.
--
Summary: gimple bytecode streams are not portable between
different hosts
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dnovillo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41526
