This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-01-17
     Ever confirmed|0                           |1

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #12)
> Created attachment 43152 [details]
> preprocessed c++ source
> 
> I was able to reduce it somewhat.  However, I'd be surprised if it does not
> reproduce the error on some other system.  I get the error only with the RX
> cross compiler
> 
> rx-elf-gcc -v
> Using built-in specs.
> COLLECT_GCC=rx-elf-gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/rx-elf/6.4.1/lto-wrapper
> Target: rx-elf
> Configured with: ../gcc-6-branch-rx/configure --target=rx-elf
> --prefix=/usr/local --enable-languages=c,c++ --disable-nls --disable-werror
> --with-newlib --enable-lto --enable-multilib --with-system-zlib
> --disable-libstdcxx-verbose --disable-symvers
> Thread model: single
> gcc version 6.4.1 20180114 (GCC)

I can reproduce it:

rguenther@murzim:/abuild/rguenther/obj-rx-elf/gcc> ./xg++ -B. t.ii -flto
-nostdlib
/usr/bin/rx-elf-ld: warning: -z relro ignored.
lto1: internal compiler error: compressed stream: data error
0xa5a0ee lto_end_uncompression(lto_compression_stream*)
        /space/rguenther/src/svn/gcc-6-branch/gcc/lto-compress.c:293
0xa57af9 lto_get_section_data(lto_file_decl_data*, lto_section_type, char
const*, unsigned long*, bool)
        /space/rguenther/src/svn/gcc-6-branch/gcc/lto-section-in.c:164
0x6df605 lto_file_finalize
        /space/rguenther/src/svn/gcc-6-branch/gcc/lto/lto.c:2038
0x6df694 lto_create_files_from_ids
        /space/rguenther/src/svn/gcc-6-branch/gcc/lto/lto.c:2055
0x6df7bb lto_file_read
        /space/rguenther/src/svn/gcc-6-branch/gcc/lto/lto.c:2096
0x6e1490 read_cgraph_and_symbols
        /space/rguenther/src/svn/gcc-6-branch/gcc/lto/lto.c:2806
0x6e252f lto_main()
        /space/rguenther/src/svn/gcc-6-branch/gcc/lto/lto.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: ./xg++ returned 1 exit status
compilation terminated.
/usr/bin/rx-elf-ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status

"Z_DATA_ERROR if the input data was
  corrupted (input stream not conforming to the zlib format or incorrect check
  value)"

We're reading LTO_section_decls at WPA time.

zlib runs into

    for (;;)
        switch (state->mode) {
        case HEAD:
...
        case BAD:
            ret = Z_DATA_ERROR;
            goto inf_leave;

caused by

        case CHECK:
            if (state->wrap) {
                NEEDBITS(32);
                out -= left;
                strm->total_out += out;
                state->total += out;
                if (out)
                    strm->adler = state->check =
                        UPDATE(state->check, put - out, out);
                out = left;
                if ((
#ifdef GUNZIP
                     state->flags ? hold :
#endif
                     ZSWAP32(hold)) != state->check) {
                    strm->msg = (char *)"incorrect data check";
                    state->mode = BAD;
                    break;

where the checksums don't match.

I honestly have no idea what goes wrong ... :/

The above is with in-tree zlib and a cross built with -O0 -g so debugging this
is possible.  Just deflate/inflate is spread across cc1plus / lto1 invocations.

The compression/data code wasn't changed between GCC 6 and trunk so the issue
is probably present/latent in GCC 7 and GCC 8 as well.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]