[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150
--- Comment #20 from Martin Liška ---
(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.
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #19 from Andrew Macleod --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #18 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Liska : https://gcc.gnu.org/g:dce5367eecfb0729cad0325240d614721afb39e3 commit r11-8867-gdce5367eecfb0729cad0325240d614721afb39e3 Author: Martin Liska 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #17 from 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 changed: > >What|Removed |Added > > CC||amacleod at redhat dot com > > --- Comment #16 from Martin Liška --- > > 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 > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 Martin Liška changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #16 from Martin Liška --- > 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 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 Martin Liška changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #15 from Martin Liška --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 Krzysztof Nowicki changed: What|Removed |Added CC||krzysztof.a.nowicki+gcc@gma ||il.com --- Comment #14 from Krzysztof Nowicki --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 David Binderman changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #13 from David Binderman --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #12 from Martin Liška --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #11 from David Binderman --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #10 from David Binderman --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #9 from David Binderman --- >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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #8 from David Binderman --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #7 from Martin Liška --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #6 from David Binderman --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #5 from Martin Liška --- and the command line please?
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #4 from David Binderman --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 Martin Liška 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #2 from David Binderman --- Starting git bisect ...
[Bug c/100150] ice in bp_unpack_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100150 --- Comment #1 from David Binderman --- Created attachment 50634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50634&action=edit x86_64 object module
