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..
