[Bug c/100150] New: ice in bp_unpack_string

[Bug c/100150] New: ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

            Bug ID: 100150
           Summary: ice in bp_unpack_string
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 50633
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50633&action=edit
x86_64 object module

For recent gcc, I get

$ /home/dcb/gcc/results/bin/gcc -o /dev/null src/bin/tolua.o
lib/libtolua++-5.3.so 
lto1: internal compiler error: Segmentation fault
0xbdfb79 crash_signal(int)
        ../../trunk.git/gcc/toplev.c:327
0x70d3a0 bp_unpack_string(data_in*, bitpack_d*)
        ../../trunk.git/gcc/data-streamer-in.c:112
0xae67df cl_optimization_stream_in(data_in*, bitpack_d*, cl_optimization*)
        /home/dcb/gcc/working/gcc/options-save.c:12731
0xe44dda streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*)
        ../../trunk.git/gcc/tree-streamer-in.c:552

The fault first seems to occur sometime between git hash 4a1493f0603262a7
and 329d2f0df7d6d22c.

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 50634
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50634&action=edit
x86_64 object module

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
Starting git bisect ...

[Bug c/100150] ice in bp_unpack_string

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2021-04-20

--- Comment #3 from Martin Liška <marxin at gcc dot gnu.org> ---
Can you please attach a pre-processed source file for src/bin/tolua.o and the
corresponding command line that was used?

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 50635
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50635&action=edit
preprocessed C source code file

[Bug c/100150] ice in bp_unpack_string

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška <marxin at gcc dot gnu.org> ---
and the command line please?

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman <dcb314 at hotmail dot com> ---
The command line seems to be:

gcc -o src/bin/tolua.o -c -g -O3 -funroll-all-loops -freport-bug -flto=auto
-ffat-lto-objects -fexceptions  -pipe -Wall -Werror=format-security
-fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection
src/bin/tolua.c

git bisect seems to indicate commit 329d2f0df7d6d22c87ab3338b94caef68139cd58,
which seems to be something about GORI, which AFAIK isn't lto related.

[Bug c/100150] ice in bp_unpack_string

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška <marxin at gcc dot gnu.org> ---
I cannot reproduce it without lib/libtolua++-5.3.so. How is libtolua++-5.3.so
built?

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #8 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Martin Liška from comment #7)
>  How is libtolua++-5.3.so built?

$ gcc -o lib/libtolua++-5.3.so -Wl,-soname,libtolua++-5.3.so -shared  
src/lib/tolua_event.os src/lib/tolua_is.os src/lib/tolua_map.os
src/lib/tolua_push.os src/lib/tolua_to.os $( -Llib $) -llua -ldl -lm

I am merely picking lines out of a build of fedora package tolua++ version
1.0.93

You might be better off trying to build the package yourself.

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #9 from David Binderman <dcb314 at hotmail dot com> ---
>From a different fedora package build, I have a much simpler test case:

$ /home/dcb/gcc/results/bin/gcc   grtter.o gruser.o

Two object modules attached.

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #10 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 50641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50641&action=edit
x86_64 object module

grtter.o

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

--- Comment #11 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 50642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50642&action=edit
x86_64 object module

gruser.o

[Bug c/100150] ice in bp_unpack_string

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to David Binderman from comment #9)
> From a different fedora package build, I have a much simpler test case:
> 
> $ /home/dcb/gcc/results/bin/gcc	  grtter.o gruser.o
> 
> Two object modules attached.

Again, please attach pre-processed source files and the corresponding command
lines.

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com]

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

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #13 from David Binderman <dcb314 at hotmail dot com> ---
It would appear that object modules generated by an old fortran 95
compiler won't mix nicely with object modules generated by new gcc.

Happily, object modules generated by new fortran 95 compiler work
lovely with object modules generated by new gcc.

It looks like no further action to me.

[Bug c/100150] ice in bp_unpack_string

[krzysztof.a.nowicki+gcc at gmail dot com]

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

Krzysztof Nowicki <krzysztof.a.nowicki+gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krzysztof.a.nowicki+gcc@gma
                   |                            |il.com

--- Comment #14 from Krzysztof Nowicki <krzysztof.a.nowicki+gcc at gmail dot com> ---
I'm seeing this very often now on my Gentoo system after upgrading from GCC
11.1 to 11.2. The cause of this ICE is well understood - the LTO bitstream is
incompatible. I however see this as a regression, as in previous GCC upgrades
the LTO linker always explicitly complained that a static library or object has
incompatible LTO data due to being built with an earlier compiler. With the
11.1 to 11.2 transition no such error happens, but the linker ICEs.

I suspect that this has happened due to introduction of an incompatible change
in the LTO bitstream without bumping the bitstream version.

This is very annoying, as previously - with the error message - it was
immediately clear which static library or object was at fault. Now with the ICE
I need to take a guess, which of one of the many libraries on the linker
command line is the problem.

[Bug c/100150] ice in bp_unpack_string

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #15 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Krzysztof Nowicki from comment #14)
> I'm seeing this very often now on my Gentoo system after upgrading from GCC
> 11.1 to 11.2. The cause of this ICE is well understood - the LTO bitstream
> is incompatible. I however see this as a regression, as in previous GCC
> upgrades the LTO linker always explicitly complained that a static library
> or object has incompatible LTO data due to being built with an earlier
> compiler. With the 11.1 to 11.2 transition no such error happens, but the
> linker ICEs.

Sorry for the inconvenience.

> 
> I suspect that this has happened due to introduction of an incompatible
> change in the LTO bitstream without bumping the bitstream version.

Looking at the git diff releases/gcc-11.1.0..releases/gcc-11.2.0, I don't see
any LTO-related change that would break the LTO stream. But it may come from a
FE.

> 
> This is very annoying, as previously - with the error message - it was
> immediately clear which static library or object was at fault. Now with the
> ICE I need to take a guess, which of one of the many libraries on the linker
> command line is the problem.

Note that we automatically bump LTO major stream version among each major
version update. But minor update (branch release) needs to be done
automatically.

We would need an automatic way how to monitor LTO stream incompatibility..

[Bug c/100150] ice in bp_unpack_string

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
> Looking at the git diff releases/gcc-11.1.0..releases/gcc-11.2.0, I don't
> see any LTO-related change that would break the LTO stream. But it may come
> from a FE.

This one is caused by change here:

commit 52f0aa4dee8401ef3958dbf789780b0ee877beab
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Mon Jun 7 13:18:55 2021 -0400

    Implement a sparse bitmap representation for Rangers on-entry cache.

    Use a sparse representation for the on entry cache, and utilize it when
    the number of basic blocks in the function exceeds
param_evrp_sparse_threshold.

            PR tree-optimization/100299
            * gimple-range-cache.cc (class sbr_sparse_bitmap): New.
            (sbr_sparse_bitmap::sbr_sparse_bitmap): New.
            (sbr_sparse_bitmap::bitmap_set_quad): New.
            (sbr_sparse_bitmap::bitmap_get_quad): New.
            (sbr_sparse_bitmap::set_bb_range): New.
            (sbr_sparse_bitmap::get_bb_range): New.
            (sbr_sparse_bitmap::bb_range_p): New.
            (block_range_cache::block_range_cache): initialize bitmap obstack.
            (block_range_cache::~block_range_cache): Destruct obstack.
            (block_range_cache::set_bb_range): Decide when to utilze the
            sparse on entry cache.
            * gimple-range-cache.h (block_range_cache): Add bitmap obstack.
            * params.opt (-param=evrp-sparse-threshold): New.

[Bug c/100150] ice in bp_unpack_string

[rguenther at suse dot de]

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

--- Comment #17 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 10 Aug 2021, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150
> 
> Martin Liška <marxin at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |amacleod at redhat dot com
> 
> --- Comment #16 from Martin Liška <marxin at gcc dot gnu.org> ---
> > Looking at the git diff releases/gcc-11.1.0..releases/gcc-11.2.0, I don't
> > see any LTO-related change that would break the LTO stream. But it may come
> > from a FE.
> 
> This one is caused by change here:
> 
> commit 52f0aa4dee8401ef3958dbf789780b0ee877beab
> Author: Andrew MacLeod <amacleod@redhat.com>
> Date:   Mon Jun 7 13:18:55 2021 -0400
> 
>     Implement a sparse bitmap representation for Rangers on-entry cache.
> 
>     Use a sparse representation for the on entry cache, and utilize it when
>     the number of basic blocks in the function exceeds
> param_evrp_sparse_threshold.
> 
>             PR tree-optimization/100299
>             * gimple-range-cache.cc (class sbr_sparse_bitmap): New.
>             (sbr_sparse_bitmap::sbr_sparse_bitmap): New.
>             (sbr_sparse_bitmap::bitmap_set_quad): New.
>             (sbr_sparse_bitmap::bitmap_get_quad): New.
>             (sbr_sparse_bitmap::set_bb_range): New.
>             (sbr_sparse_bitmap::get_bb_range): New.
>             (sbr_sparse_bitmap::bb_range_p): New.
>             (block_range_cache::block_range_cache): initialize bitmap obstack.
>             (block_range_cache::~block_range_cache): Destruct obstack.
>             (block_range_cache::set_bb_range): Decide when to utilze the
>             sparse on entry cache.
>             * gimple-range-cache.h (block_range_cache): Add bitmap obstack.
>             * params.opt (-param=evrp-sparse-threshold): New.

Altering any *.opt can indeed cause compatibility breakage.  Streaming
options in a less fragile way would be nice.

[Bug c/100150] ice in bp_unpack_string

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Martin Liska
<marxin@gcc.gnu.org>:

https://gcc.gnu.org/g:dce5367eecfb0729cad0325240d614721afb39e3

commit r11-8867-gdce5367eecfb0729cad0325240d614721afb39e3
Author: Martin Liska <mliska@suse.cz>
Date:   Mon Aug 16 13:02:54 2021 +0200

    LTO: bump minor version

    Bump the LTO_minor_version due to changes in
52f0aa4dee8401ef3958dbf789780b0ee877beab

            PR c/100150

    gcc/ChangeLog:

            * lto-streamer.h (LTO_minor_version): Bump.

[Bug c/100150] ice in bp_unpack_string

[amacleod at redhat dot com]

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

--- Comment #19 from Andrew Macleod <amacleod at redhat dot com> ---
So what kinds of changes trigger this?  That patch added a new --param option.
Will this happen every time a --param option is added?

what about changing a param option? because I am about to tweak the options to
--param=evrp-mode to add some additional debugging modes as well.

[Bug c/100150] ice in bp_unpack_string

[marxin at gcc dot gnu.org]

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

--- Comment #20 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #19)
> So what kinds of changes trigger this?  That patch added a new --param
> option.
> Will this happen every time a --param option is added?
> 
> what about changing a param option? because I am about to tweak the options
> to --param=evrp-mode to add some additional debugging modes as well.

It will likely cause troubles, see how cl_optimization_stream_{in,out} (in
options-save.c) is going to change.