On 6/24/19 2:02 PM, Richard Biener wrote: > On Fri, Jun 21, 2019 at 4:01 PM Martin Liška <mli...@suse.cz> wrote: >> >> On 6/21/19 2:57 PM, Jan Hubicka wrote: >>> This looks like good step (and please stream it in host independent >>> way). I suppose all these issues can be done one-by-one. >> >> So there's a working patch for that. However one will see following errors >> when using an older compiler or older LTO bytecode: >> >> $ gcc main9.o -flto >> lto1: fatal error: bytecode stream in file ‘main9.o’ generated with LTO >> version -25480.4493 instead of the expected 9.0 >> >> $ gcc main.o >> lto1: internal compiler error: compressed stream: data error > > This is because of your change to bitfields or because with the old > scheme the header with the > version is compressed (is it?).
Because currently also the header is compressed. > I'd simply avoid any layout changes > in the version check range. Well, then we have to find out how to distinguish between compression algorithms. > >> To be honest, I would prefer the new .gnu.lto_.meta section. >> Richi why is that so ugly? > > Because it's a change in the wrong direction and doesn't solve the > issue we already > have (cannot determine if a section is compressed or not). That's not true, the .gnu.lto_.meta section will be always uncompressed and we can also backport changes to older compiler that can read it and print a proper error message about LTO bytecode version mismatch. > ELF section overhead > is quite big if you have lots of small functions. My patch is actually shrinking space as I'm suggesting to add _one_ extra ELF section and remove the section header from all other LTO sections. That will save space for all function sections. Martin > > Richard. > >> >> Martin
