Summary: | sys-devel/gcc-10.2.0: lto1: internal compiler error: bytecode stream: expected tag identifier_node instead of LTO_UNKNOWN | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Johannes Hirte <johannes.hirte> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED INVALID | ||
Severity: | critical | CC: | sam, slyfox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
environment |
Description
Johannes Hirte
2020-07-25 13:39:06 UTC
Created attachment 650706 [details]
build.log
Created attachment 650708 [details]
environment
> -static Given that you are using static linking with lto make sure you have rebuilt all static libraries with new gcc: https://gcc.gnu.org/PR62083 (In reply to Sergei Trofimovich from comment #3) > > -static > > Given that you are using static linking with lto make sure you have rebuilt > all static libraries with new gcc: https://gcc.gnu.org/PR62083 I've enabled lto selective for some packages, but not for qemu. Does this error come from a package build with lto and is linked in by qemu? I'm suspecting glib. (In reply to Johannes Hirte from comment #4) > (In reply to Sergei Trofimovich from comment #3) > > > -static > > > > Given that you are using static linking with lto make sure you have rebuilt > > all static libraries with new gcc: https://gcc.gnu.org/PR62083 > > I've enabled lto selective for some packages, but not for qemu. Does this > error come from a package build with lto and is linked in by qemu? I'm > suspecting glib. Oh, that's an interesting failure mode. Yeah, that might be it. Ideally such static libraries should be built with -ffat-lto-objects, so these .a files could be used in non-lto contexts. (In reply to Johannes Hirte from comment #4) > (In reply to Sergei Trofimovich from comment #3) > > > -static > > > > Given that you are using static linking with lto make sure you have rebuilt > > all static libraries with new gcc: https://gcc.gnu.org/PR62083 > > I've enabled lto selective for some packages, but not for qemu. Does this > error come from a package build with lto and is linked in by qemu? I'm > suspecting glib. Nailed it! Re-emerging dev-libs/glib solved it. I'm building dev-libs/glib with the this flags: COMMON_FLAGS="-O2 -ggdb -flto=8 -fuse-linker-plugin -march=znver1 -mtune=znver1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -ftree-vectorize -fvect-cost-model -pipe" CFLAGS="${COMMON_FLAGS}" CXXFLAGS="${COMMON_FLAGS}" FCFLAGS="${COMMON_FLAGS}" FFLAGS="${COMMON_FLAGS}" LDFLAGS="${LDFLAGS} ${COMMON_FLAGS}" FEATURES="${FEATURES} splitdebug" MAKEOPTS="-j8 -l8" (In reply to Johannes Hirte from comment #6) > (In reply to Johannes Hirte from comment #4) > > (In reply to Sergei Trofimovich from comment #3) > > > > -static > > > > > > Given that you are using static linking with lto make sure you have rebuilt > > > all static libraries with new gcc: https://gcc.gnu.org/PR62083 > > > > I've enabled lto selective for some packages, but not for qemu. Does this > > error come from a package build with lto and is linked in by qemu? I'm > > suspecting glib. > > Nailed it! Re-emerging dev-libs/glib solved it. I'm building dev-libs/glib > with the this flags: Glad you've nailed it! If the mere rebuid was enough then it probably was a mismatch of lto formats (or contents) across gcc versions. |