public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/41526]  New: gimple bytecode streams are not portable between different hosts
@ 2009-09-30 19:37 dnovillo at gcc dot gnu dot org
  2009-09-30 19:50 ` [Bug lto/41526] " dnovillo at gcc dot gnu dot org
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: dnovillo at gcc dot gnu dot org @ 2009-09-30 19:37 UTC (permalink / raw)
  To: gcc-bugs

>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


^ permalink raw reply	[flat|nested] 9+ messages in thread
[parent not found: <bug-41526-4@http.gcc.gnu.org/bugzilla/>]
end of thread, other threads:[~2022-07-04  9:28 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-09-30 19:37 [Bug lto/41526] New: gimple bytecode streams are not portable between different hosts dnovillo at gcc dot gnu dot org
2009-09-30 19:50 ` [Bug lto/41526] " dnovillo at gcc dot gnu dot org
2009-09-30 20:17 ` dnovillo at gcc dot gnu dot org
2010-09-01 19:30 ` jsm28 at gcc dot gnu dot org
     [not found] <bug-41526-4@http.gcc.gnu.org/bugzilla/>
2021-12-26  2:07 ` pinskia at gcc dot gnu.org
2022-05-18 12:43 ` rguenth at gcc dot gnu.org
2022-07-04  8:41 ` rguenth at gcc dot gnu.org
2022-07-04  9:03 ` rguenth at gcc dot gnu.org
2022-07-04  9:28 ` richard at weickelt dot de

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).