>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