https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816
--- Comment #17 from Oleg Endo <olegendo at gcc dot gnu.org> --- (In reply to Richard Biener from comment #15) > > I can reproduce it: > Nice. (In reply to Richard Biener from comment #16) > Note your testcase only reproduces on the GCC 6 branch. It is expected that > the issue happens because of some exact length of the uncompressed or > compressed section or maybe even the actual contents... This particular case, yes. However, I ran into this originally with GCC 7. During app development GCC 7 started to bail out while GCC 6 was working OK. So I switched back to GCC 6 and after some more app development, that one started bailing out and GCC 7 does not on that case. So I'd assume the issue is present in all versions. > > Do you run into this very often? > No, I can't say often. But it surely is very annoying. And when it happens the only practical fix is to turn off LTO, which has a significant negative impact on the code size. > It may be possible to extract a "zlib testcase" ... maybe it is a genuine > bug in it? (however unlikely that is...) Somehow I doubt that. I'm now adding some logging around the code in lto-compress.c but so far I'm not getting any useful info out of it. The decompression fails right at the first block in the stream.
