[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282

["davek at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #14 from davek at gcc dot gnu dot org  2010-01-17 16:07 -------
(In reply to comment #13)

> Maybe.  Or simply store the size of the compressed blob at the beginning?

Yep, of course.  The padding trick is kinda neat because you can do it on the
fly at the end of writing the data without having to rewind the file, but
they'll both serve the job perfectly well.

> (Not that I have spent too much time with looking how zlib works)
> 
> > Apropos this particular patch, I see you've structured things so that the start
> > of each section is aligned, but the size is one-byte granular.  Is this
> > alignment necessary for any reason apart from allowing RISC machines to read
> > the words and half-words in the lto header struct without any worries about
> > misaligned access when using mmap?
> 
> Yes, that was the reason.  

That's convenient, as it gives me an option for a more minimal change to the
COFF assembler (at least until I want to worry about supporting non-x86 coff
platforms, anyway...)

> There was even a bug about this somewhen
> somewhere ...

  Ah, ITYM Bug 40754.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392