Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 788661 - <sys-devel/binutils-2.36-r1 : gold is not compatible to sys-devel/gcc-11.1.0's dwarf-5, causes random SIGSEGVs
Summary: <sys-devel/binutils-2.36-r1 : gold is not compatible to sys-devel/gcc-11.1.0'...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL: https://sourceware.org/PR27246
Whiteboard:
Keywords:
Depends on: binutils-2.37-stable
Blocks: gcc-11
  Show dependency tree
 
Reported: 2021-05-06 23:45 UTC by Steffen Hau
Modified: 2021-10-09 16:35 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (sys-devel-gcc-11.1.0_build.log.xz,155.86 KB, application/x-xz)
2021-05-06 23:47 UTC, Steffen Hau
Details
gcc differing objects between stage 2 and 3 (gcc-differing-objects.tar.xz,481.12 KB, application/x-xz)
2021-05-07 07:43 UTC, Steffen Hau
Details
gcc-11-unstable-bug-788661.tar.gz (gcc-11-unstable-bug-788661.tar.gz,158.70 KB, application/gzip)
2021-05-07 21:35 UTC, Sergei Trofimovich (RETIRED)
Details
libstdc++ stage{2,3} config.log (libstddc++-config.log.tar.xz,28.90 KB, application/x-xz)
2021-05-08 10:34 UTC, Steffen Hau
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steffen Hau 2021-05-06 23:45:34 UTC
I've upgraded my ~amd64 systems and after GCC 11.1.0 has been installed and emerge --depclean has uninstalled GCC 10.20 I ran emerge -ve @world and GCC 11.1.0 has failed. Each consecutive attempt to build GCC 11.1.0 now failes with

Comparing stages 2 and 3
Bootstrap comparison failure!
x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/vterminate.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/compatibility-condvar.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/compatibility-atomic-c++0x.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs/compatibility-condvar.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs/compatibility-atomic-c++0x.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs/compatibility-thread-c++0x.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs/compatibility-c++0x.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs/compatibility.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/compatibility-thread-c++0x.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++98/ext-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++98/locale_init.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++98/localename.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++98/ios_init.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++98/basic_file.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++98/globals_io.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++20/sstream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/debug.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-wstring-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/thread.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/random.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/ctype_configure_char.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/iostream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/wstring-io-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-wstring-io-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/ios-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/wstring-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/future.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/ostream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/condition_variable.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/system_error.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/ext11-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/codecvt.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/ctype_members.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/regex.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cxx11-wlocale-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/sstream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/functexcept.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cxx11-locale-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/snprintf_lite.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/locale-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-string-io-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cxx11-ios_failure.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-locale_init.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/string-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cxx11-shim_facets.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/streambuf-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-string-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-stdexcept.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/ios.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/fstream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/istream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-shim_facets.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/ctype.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cxx11-hash_tr1.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/sso_string.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/string-io-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cxx11-stdexcept.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/wlocale-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-fstream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/cow-sstream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++11/mutex.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/cow-ops.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/ops.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/cow-path.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/cow-dir.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/path.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/filesystem/dir.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/cow-fs_dir.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/floating_to_chars.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/ostream-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/cow-fs_path.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/floating_from_chars.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/memory_resource.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/cow-fs_ops.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/fs_path.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/string-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/cow-string-inst.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/fs_ops.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/c++17/fs_dir.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/compatibility-c++0x.o differs
x86_64-pc-linux-gnu/32/libstdc++-v3/src/compatibility.o differs


emerge --info gcc
Portage 3.0.18 (python 3.9.4-final-0, default/linux/amd64/17.1/systemd, gcc-11.1.0, glibc-2.33, 5.12.0-HAUIHAU x86_64)
=================================================================
                         System Settings
=================================================================
System uname: Linux-5.12.0-HAUIHAU-x86_64-Intel-R-_Core-TM-_i5-10210U_CPU_@_1.60GHz-with-glibc2.33
KiB Mem:    32604432 total,  22105932 free
KiB Swap:   16777212 total,  15611900 free
Timestamp of repository gentoo: Thu, 06 May 2021 14:35:12 +0000
Head commit of repository gentoo: c6909450bc6738d13c1a7440863547d4be52a1cb

sh bash 5.1_p4
ld GNU gold (Gentoo 2.36.1 p3 2.36.1) 1.16
app-shells/bash:          5.1_p4::gentoo
dev-java/java-config:     2.3.1::gentoo
dev-lang/perl:            5.32.1::gentoo
dev-lang/python:          2.7.18_p8::gentoo, 3.9.4::gentoo
dev-lang/rust:            1.51.0-r2::gentoo
dev-util/cmake:           3.20.2::gentoo
sys-apps/baselayout:      2.7-r2::gentoo
sys-apps/sandbox:         2.23::gentoo
sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake:       1.16.3-r1::gentoo
sys-devel/binutils:       2.36.1-r1::gentoo
sys-devel/gcc:            11.1.0::gentoo
sys-devel/gcc-config:     2.4::gentoo
sys-devel/libtool:        2.4.6-r6::gentoo
sys-devel/make:           4.3::gentoo
sys-kernel/linux-headers: 5.12::gentoo (virtual/os-headers)
sys-libs/glibc:           2.33::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: git
    sync-uri: https://github.com/gentoo-mirror/gentoo.git
    priority: -1000

hauihau
    location: /var/db/repos/hauihau
    masters: gentoo
    priority: 0

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O3 -pipe -flto=9 -fuse-linker-plugin"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -O3 -pipe -flto=9 -fuse-linker-plugin"
DISTDIR="/home/gentoo/distfiles/"
EMERGE_DEFAULT_OPTS="--autounmask=n --keep-going=y --quiet-build=y --quiet-fail=y --with-bdeps=y --changed-deps-report=n"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fakeroot fixlafiles ipc-sandbox merge-sync metadata-transfer multilib-strict network-sandbox news parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="de_DE.UTF-8"
LC_ALL="de_DE.UTF-8"
LDFLAGS="-march=native -O3 -pipe -flto=9 -fuse-linker-plugin -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--gc-sections -Wl,--icf=safe"
LINGUAS="de"
MAKEOPTS="-j9"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/home/gentoo/tmp/"
USE="X a52 aac aalib acl alsa amd64 avx avx2 bash-completion berkdb bluetooth bluray branding bzip2 cairo caps cdda cddb cdparanoia cdr cli crypt cups curl cxx dbus dga dri dts dv dvd egl encode exif ffmpeg flac fontconfig fortran ftp gd gdbm gif gmp gstreamer iconv icu imagemagick imlib ipv6 jpeg jpeg2k kde kerberos lame libcaca libglvnd libnotify libsamplerate libtirpc lzma lzo mad matroska mmx mmxext mng mp3 mpeg mtp multilib musepack ncurses networkmanager nls nptl nsplugin ogg openal opengl openmp opus pam pcre pdf png policykit pulseaudio qt5 quicktime readline seccomp sndfile spell split-usr sse sse2 sse3 sse4 sse4_1 sse4_2 ssl ssse3 svg syslog systemd tcpd theora threads tiff truetype udev unicode upower usb v4l vaapi vcd vim-syntax vorbis wavpack wayland webkit x264 xattr xcb xcomposite xinerama xml xmp xorg xosd xpm xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="libinput" KERNEL="linux" L10N="de" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_9" PYTHON_TARGETS="python3_9" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby30" USERLAND="GNU" VIDEO_CARDS="i965 intel iris" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RUSTFLAGS

=================================================================
                        Package Settings
=================================================================

sys-devel/gcc-11.1.0::gentoo was built with the following:
USE="(cxx) fortran lto (multilib) nls nptl openmp pch (pie) sanitize ssp (-ada) -custom-cflags -d -debug -doc (-fixed-point) -go -graphite (-hardened) -jit (-libssp) -objc -objc++ -objc-gc -pgo -systemtap -test -valgrind -vanilla -vtv -zstd" ABI_X86="(64)"
CFLAGS="-march=native -pipe -O2"
CXXFLAGS="-march=native -pipe -O2"
FEATURES="usersandbox news strict merge-sync config-protect-if-modified multilib-strict protect-owned ipc-sandbox xattr ebuild-locks binpkg-dostrip preserve-libs userpriv metadata-transfer parallel-fetch parallel-install sfperms fixlafiles assume-digests unmerge-logs binpkg-docompress fakeroot binpkg-logs pid-sandbox distlocks unmerge-orphans qa-unresolved-soname-deps unknown-features-warn sandbox usersync userfetch network-sandbox"
LDFLAGS="-march=native -pipe -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--gc-sections -Wl,--icf=safe"


The build.log

Reproducible: Always
Comment 1 Steffen Hau 2021-05-06 23:47:07 UTC
Created attachment 706434 [details]
build.log
Comment 2 Sam James archtester gentoo-dev Security 2021-05-06 23:52:02 UTC
- try vanilla CFLAGS? Any difference?
- what about if you disable gold?
Comment 3 Steffen Hau 2021-05-06 23:56:33 UTC
(In reply to Sam James from comment #2)
> - try vanilla CFLAGS? Any difference?
> - what about if you disable gold?

These look very vanilla for me:
CFLAGS="-march=native -pipe -O2"
CXXFLAGS="-march=native -pipe -O2"

Do you want me to test any specific CFLAGS?


GCC compared object files, at that stage no linker is involved afaik.

But I will give it a try, if you would like to share any suggestions regarding *FLAGS I would be thankful.
Comment 4 Sam James archtester gentoo-dev Security 2021-05-07 00:06:29 UTC
(In reply to Steffen Hau from comment #3)
> (In reply to Sam James from comment #2)
> > - try vanilla CFLAGS? Any difference?
> > - what about if you disable gold?
> 
> These look very vanilla for me:
> CFLAGS="-march=native -pipe -O2"
> CXXFLAGS="-march=native -pipe -O2"
> 

I missed the specific part at the bottom ;)


> Do you want me to test any specific CFLAGS?
> 

I’ll let slyfox suggest things rather than guess for now, but if you’re bored, completely vanilla LDFLAGS just in case (given that GCC will build a compiler to use in subsequent stages)?
> 
> GCC compared object files, at that stage no linker is involved afaik.
> 

See above. But maybe I’m misremembering which stage that is in.

> But I will give it a try, if you would like to share any suggestions
> regarding *FLAGS I would be thankful.
Comment 5 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-07 06:31:14 UTC
Please attach one diffing object file from stage2 and stage3 for comparison.
Comment 6 Steffen Hau 2021-05-07 07:43:39 UTC
Created attachment 706470 [details]
gcc differing objects between stage 2 and 3
Comment 7 Steffen Hau 2021-05-07 07:45:18 UTC
(In reply to Sergei Trofimovich from comment #5)
> Please attach one diffing object file from stage2 and stage3 for comparison.

Let me know if you need more object files to check.

Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0 being the active compiler?
Comment 8 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-07 17:13:15 UTC
(In reply to Steffen Hau from comment #7)
> (In reply to Sergei Trofimovich from comment #5)
> > Please attach one diffing object file from stage2 and stage3 for comparison.
> 
> Let me know if you need more object files to check.

Thank you! Will do. I'll need some time to run a gcc-specific diff locally. At lest so far generated code is identical:

$ diff -u <(h objdump -d stage2-floating_to_chars.o) <(h objdump -d stage3-floating_to_chars.o)
--- /dev/fd/63  2021-05-07 18:10:06.108739068 +0100
+++ /dev/fd/62  2021-05-07 18:10:06.108739068 +0100
@@ -1,5 +1,5 @@

-stage2-floating_to_chars.o:     file format elf32-i386
+stage3-floating_to_chars.o:     file format elf32-i386

> Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0
> being the active compiler?

Works fine for me here, but it's a USE=-lto system. I'll try USE=lto in a chroot.

Source compiler should not matter as stage2/3 should be build by locale gcc-11.
Comment 9 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-07 18:10:42 UTC
gcc uses the following tool to compare files (nothing complicated, phew):

  from build.log:
    checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2

  from Makefile.in:
    do-compare = @do_compare@
    ...

    compare:
        ....
        echo Comparing stages 2 and 3; \
        sed=`echo stage3 | sed 's,^stage,,;s,.,.,g'`; \
        files=`find stage3-* -name "*$(objext)" -print | \
                 sed -n s,^stage$$sed-,,p`; \
        for file in $${files} ${extra-compare}; do \
          f1=$$r/stage2-$$file; f2=$$r/stage3-$$file; \
          if test ! -f $$f1; then continue; fi; \
          $(do-compare) > /dev/null 2>&1; \
          if test $$? -eq 1; then \
            case $$file in \
              @compare_exclusions@) \
                echo warning: $$file differs ;; \
              *) \
                echo $$file differs >> .bad_compare ;; \

Thus these should be byte-identical (modulo ELF's 16-byte magic+flags). But they are obviously different for you.

Looking at first different lines of `readelf -W -a`:



  [23] .text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 PROGBITS        00000000 000170 00002b 00  AX  0   0 16
  [24] .rel.text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 REL             00000000 066c64 000030 08   I 239  23  4

  [23] .text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 PROGBITS        00000000 000170 00002b 00  AX  0   0 16
  [24] .rel.text._ZN12_GLOBAL__N_13ryuL9log10Pow2Ei.part.0 REL             00000000 066c40 000030 08   I 239  23  4

Note the file offset: 066c40 / 066c64. Stripping files generates identical binaries.

This means gcc generates non-deterministic debug info for your case. Interestingly only for -m32 case.
It might be gcc or might be binutils. We will need to narrow it down.

Can you expand -march=native for your system?

Via something like https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide#Expand_-march.3Dnative.2C_exact_gcc_version_and_other_system-specific_options
Comment 10 Steffen Hau 2021-05-07 18:43:46 UTC
(In reply to Sergei Trofimovich from comment #8)
> Thank you! Will do. I'll need some time to run a gcc-specific diff locally.
> At lest so far generated code is identical:
> 
> $ diff -u <(h objdump -d stage2-floating_to_chars.o) <(h objdump -d
> stage3-floating_to_chars.o)
> --- /dev/fd/63  2021-05-07 18:10:06.108739068 +0100
> +++ /dev/fd/62  2021-05-07 18:10:06.108739068 +0100
> @@ -1,5 +1,5 @@
> 
> -stage2-floating_to_chars.o:     file format elf32-i386
> +stage3-floating_to_chars.o:     file format elf32-i386
> 
> > Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0
> > being the active compiler?
> 
> Works fine for me here, but it's a USE=-lto system. I'll try USE=lto in a
> chroot.
> 
> Source compiler should not matter as stage2/3 should be build by locale
> gcc-11.
I thought that lto use flag is to make LTO feature available, I didn't know that lto is used for bootstrapping when use flag is enabled.














(In reply to Sergei Trofimovich from comment #9)
> This means gcc generates non-deterministic debug info for your case.
> Interestingly only for -m32 case.
> It might be gcc or might be binutils. We will need to narrow it down.
Ok, let me know if I can help.

> 
> Can you expand -march=native for your system?
arch=skylake; for t in param target; do cmd="gcc -Q -O2 -march=$arch --help=$t"; diff -U0 <(LANG=C $cmd) <(LANG=C $cmd -march=native); done
--- /dev/fd/63  2021-05-07 20:35:46.849957140 +0200
+++ /dev/fd/62  2021-05-07 20:35:46.850957157 +0200
@@ -84,2 +84,2 @@
-  --param=l1-cache-size=               64
-  --param=l2-cache-size=               512
+  --param=l1-cache-size=               32
+  --param=l2-cache-size=               6144
--- /dev/fd/63  2021-05-07 20:35:46.872957519 +0200
+++ /dev/fd/62  2021-05-07 20:35:46.872957519 +0200
@@ -12 +12 @@
-  -mabm                                [disabled]
+  -mabm                                [enabled]

For reference, here is also the complete argument list when -march=native is used:
gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
 /usr/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/cc1 -E -quiet -v - -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake -dumpbase -
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-07 21:34:49 UTC
(In reply to Steffen Hau from comment #10)
> (In reply to Sergei Trofimovich from comment #8)
> > Thank you! Will do. I'll need some time to run a gcc-specific diff locally.
> > At lest so far generated code is identical:
> > 
> > $ diff -u <(h objdump -d stage2-floating_to_chars.o) <(h objdump -d
> > stage3-floating_to_chars.o)
> > --- /dev/fd/63  2021-05-07 18:10:06.108739068 +0100
> > +++ /dev/fd/62  2021-05-07 18:10:06.108739068 +0100
> > @@ -1,5 +1,5 @@
> > 
> > -stage2-floating_to_chars.o:     file format elf32-i386
> > +stage3-floating_to_chars.o:     file format elf32-i386
> > 
> > > Did you try to rebuild GCC 11.1.0 after it has been emerged with GCC 11.1.0
> > > being the active compiler?
> > 
> > Works fine for me here, but it's a USE=-lto system. I'll try USE=lto in a
> > chroot.
> > 
> > Source compiler should not matter as stage2/3 should be build by locale
> > gcc-11.
> I thought that lto use flag is to make LTO feature available, I didn't know
> that lto is used for bootstrapping when use flag is enabled.

Long ago USE=lto used to enable gcc's lto backend. Nowadays lto backend is always enabled. USE=lto (similar to other packages) enables bootstra-lto.

> (In reply to Sergei Trofimovich from comment #9)
> > This means gcc generates non-deterministic debug info for your case.
> > Interestingly only for -m32 case.
> > It might be gcc or might be binutils. We will need to narrow it down.
> Ok, let me know if I can help.
> 
> > 
> > Can you expand -march=native for your system?
> arch=skylake; for t in param target; do cmd="gcc -Q -O2 -march=$arch
> --help=$t"; diff -U0 <(LANG=C $cmd) <(LANG=C $cmd -march=native); done
> --- /dev/fd/63  2021-05-07 20:35:46.849957140 +0200
> +++ /dev/fd/62  2021-05-07 20:35:46.850957157 +0200
> @@ -84,2 +84,2 @@
> -  --param=l1-cache-size=               64
> -  --param=l2-cache-size=               512
> +  --param=l1-cache-size=               32
> +  --param=l2-cache-size=               6144
> --- /dev/fd/63  2021-05-07 20:35:46.872957519 +0200
> +++ /dev/fd/62  2021-05-07 20:35:46.872957519 +0200
> @@ -12 +12 @@
> -  -mabm                                [disabled]
> +  -mabm                                [enabled]
> 
> For reference, here is also the complete argument list when -march=native is
> used:
> gcc -march=native -E -v - </dev/null 2>&1 | grep cc1
>  /usr/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/cc1 -E -quiet -v -
> -march=skylake -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2
> -mavx -mavx2 -mno-sse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2
> -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd
> -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma
> -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2
> -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16
> -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt
> -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle
> -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mno-mwaitx
> -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid
> -mrdrnd -mrdseed -mno-rtm -mno-serialize -msgx -mno-sha -mno-shstk -mno-tbm
> -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mxsavec
> -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr
> -mno-hreset -mno-kl -mno-widekl -mno-avxvnni --param l1-cache-size=32
> --param l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=skylake
> -dumpbase -

Aha, I tried to extract a small bit of libstdc and tried to compile it with your -march= and other options. I don't see a fluctuation of output:

$ ./mk.bash
008de0f156109084c45f59f73b651cd92708edc0  floating_to_chars.o1
008de0f156109084c45f59f73b651cd92708edc0  floating_to_chars.o2
008de0f156109084c45f59f73b651cd92708edc0  floating_to_chars.o3

There is a tiny chance that headers are somehow different at build (or other bugs I introduced by accident). I wonder if the minimal test will fail for you. I'll attach a tarball with test in a second.
Comment 12 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-07 21:35:14 UTC
Created attachment 706560 [details]
gcc-11-unstable-bug-788661.tar.gz
Comment 13 Steffen Hau 2021-05-07 21:46:01 UTC
./mk.bash 
8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o1
8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o2
8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o3

Is there a difference in mk.bash I can't spot at the lines creating o1 and o2?

As someone had binutils in mind: they were updated (2.35.2 -> 2.36.1-r1) in the same merge where gcc 11.1.0 was installed.
Comment 14 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-07 22:20:28 UTC
(In reply to Steffen Hau from comment #13)
> ./mk.bash 
> 8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o1
> 8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o2
> 8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o3
> 
> Is there a difference in mk.bash I can't spot at the lines creating o1 and
> o2?

They should be the same. I extracted all calls from your build log.

> As someone had binutils in mind: they were updated (2.35.2 -> 2.36.1-r1) in
> the same merge where gcc 11.1.0 was installed.

Do you know the ordering?
    $ qlop -muv gcc binutils
should show it.

In theory gcc might have embedded binutils-based property into one of stages, but not the other (normally it should not).
Comment 15 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-07 22:50:41 UTC
I also noticed that your stage2 file contains 'tmpnam' symbol in .debug_str, while stage3 does not.

I wonder if libstdc++ for stage2/3 detected different value of _GLIBCXX_USE_TMPNAM

libstdc++-v3/include/c_global/cstdio:#if _GLIBCXX_USE_TMPNAM
libstdc++-v3/include/c_global/cstdio-  using ::tmpnam;
libstdc++-v3/include/c_global/cstdio-#endif

It should be visible in config.h of libstdc++-v3. Or on config.log

Your build.log is curiously inconsistent about it:

$ cat sys-devel-gcc-11.1.0_build.log | fgrep tmpnam
checking for tmpnam... config.status: creating Makefile
checking for tmpnam... yes
checking for tmpnam... no
checking for tmpnam... yes
checking for tmpnam... yes
checking for tmpnam... no
checking for tmpnam... yes
checking for tmpnam... yes
checking for tmpnam... no
checking for tmpnam... no

But it might be just parallel output problem. Mine is full of garbage, but at least it never says `no`:

$ cat sys-devel:gcc-11.1.0:20210427-173430.log | fgrep tmpnam
checking for tmpnam... yes
checking for vsprintf... checking for tmpnam... yes
checking for tmpnam... mv -f .deps/affinity-fmt.Tpo .deps/affinity-fmt.Plo
checking for tmpnam... yes
checking stdio.h usability... checking for tmpnam... yes
checking for tmpnam... /bin/bash ....
checking for tmpnam... yes
checking for tmpnam... 4
checking for tmpnam... yes
checking for tmpnam... yes
Comment 16 Steffen Hau 2021-05-08 08:57:34 UTC
(In reply to Sergei Trofimovich from comment #14)
> (In reply to Steffen Hau from comment #13)
> > ./mk.bash 
> > 8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o1
> > 8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o2
> > 8a1a7e096786ca718925ff445b38725673557420  floating_to_chars.o3
> > 
> > Is there a difference in mk.bash I can't spot at the lines creating o1 and
> > o2?
> 
> They should be the same. I extracted all calls from your build log.
> 
> > As someone had binutils in mind: they were updated (2.35.2 -> 2.36.1-r1) in
> > the same merge where gcc 11.1.0 was installed.
> 
> Do you know the ordering?
>     $ qlop -muv gcc binutils
> should show it.
emerge -uvDU
2021-05-02T00:04:49 >>> sys-devel/binutils-2.36.1-r1
2021-05-02T00:10:07 >>> sys-devel/gcc-11.1.0

emerge --depclean
2021-05-02T21:38:30 <<< sys-devel/gcc-10.3.0
2021-05-02T21:38:45 <<< sys-devel/binutils-2.35.2

emerge -ve @world
2021-05-04T02:07:45 >>> sys-devel/binutils-2.36.1-r1
2021-05-04T02:12:29 failed sys-devel/gcc-11.1.0 


(In reply to Sergei Trofimovich from comment #15)
> I also noticed that your stage2 file contains 'tmpnam' symbol in .debug_str,
> while stage3 does not.
> 
> I wonder if libstdc++ for stage2/3 detected different value of
> _GLIBCXX_USE_TMPNAM
> 
> libstdc++-v3/include/c_global/cstdio:#if _GLIBCXX_USE_TMPNAM
> libstdc++-v3/include/c_global/cstdio-  using ::tmpnam;
> libstdc++-v3/include/c_global/cstdio-#endif
> 
> It should be visible in config.h of libstdc++-v3. Or on config.log
> 
> Your build.log is curiously inconsistent about it:
> 
> $ cat sys-devel-gcc-11.1.0_build.log | fgrep tmpnam
> checking for tmpnam... config.status: creating Makefile
> checking for tmpnam... yes
> checking for tmpnam... no
> checking for tmpnam... yes
> checking for tmpnam... yes
> checking for tmpnam... no
> checking for tmpnam... yes
> checking for tmpnam... yes
> checking for tmpnam... no
> checking for tmpnam... no
> 
> But it might be just parallel output problem. Mine is full of garbage, but
> at least it never says `no`:
> 
> $ cat sys-devel:gcc-11.1.0:20210427-173430.log | fgrep tmpnam
> checking for tmpnam... yes
> checking for vsprintf... checking for tmpnam... yes
> checking for tmpnam... mv -f .deps/affinity-fmt.Tpo .deps/affinity-fmt.Plo
> checking for tmpnam... yes
> checking stdio.h usability... checking for tmpnam... yes
> checking for tmpnam... /bin/bash ....
> checking for tmpnam... yes
> checking for tmpnam... 4
> checking for tmpnam... yes
> checking for tmpnam... yes
This exceeds my knowledge. Should I tar the complete build dir so that you can have a look into it? I can send you a download link.
Comment 17 Steffen Hau 2021-05-08 08:59:39 UTC
As you mentioned glibc, the last glibc merges:

emerge -uvDU @world
2021-04-14T09:33:21 >>> sys-libs/glibc-2.33

emerge -ve @world
2021-05-04T04:37:33 >>> sys-libs/glibc-2.33
Comment 18 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-08 10:15:26 UTC
> > $ cat sys-devel:gcc-11.1.0:20210427-173430.log | fgrep tmpnam
> > checking for tmpnam... yes
> > checking for vsprintf... checking for tmpnam... yes
> > checking for tmpnam... mv -f .deps/affinity-fmt.Tpo .deps/affinity-fmt.Plo
> > checking for tmpnam... yes
> > checking stdio.h usability... checking for tmpnam... yes
> > checking for tmpnam... /bin/bash ....
> > checking for tmpnam... yes
> > checking for tmpnam... 4
> > checking for tmpnam... yes
> > checking for tmpnam... yes
> This exceeds my knowledge. Should I tar the complete build dir so that you
> can have a look into it? I can send you a download link.

`config.log` from all directories should be sufficient. `tmpnam` is a simple link test that ries to link something like
    #include <stdio.h>
    int main() { char *tmp = tmpnam(NULL); 
to detect `tmpnam` presence. We need to find a `config.log` that failed to link it and reported broken tmpnam.
Comment 19 Steffen Hau 2021-05-08 10:32:42 UTC
diff -Naur stage2-libstdc++-32bit-config.log stage3-libstdc++-32bit-config.log
[snip]
 configure:21172: checking for tmpnam
-configure:21210: /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc -shared-libgcc -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++ -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32 -o conftest -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions   conftest.cpp  >&5
-/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/cc2GI8iw.o:conftest.cpp:function main: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
-configure:21210: $? = 0
-configure:21226: result: yes
+configure:21210: /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc -shared-libgcc -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++ -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1  -m32 -o conftest -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions   conftest.cpp  >&5
+collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
+compilation terminated.
+configure:21210: $? = 1


This is the difference between the compiler arguments:
@@ -11,7 +11,7 @@
 /usr/x86_64-pc-linux-gnu/include
 -isystem
 /usr/x86_64-pc-linux-gnu/sys-include
--fno-checking
+-fchecking=1

I'll attach both config.logs.
Comment 20 Steffen Hau 2021-05-08 10:34:53 UTC
Created attachment 706617 [details]
libstdc++ stage{2,3} config.log
Comment 21 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-08 11:33:20 UTC
(In reply to Steffen Hau from comment #19)
> diff -Naur stage2-libstdc++-32bit-config.log
> stage3-libstdc++-32bit-config.log
> [snip]
>  configure:21172: checking for tmpnam
> -configure:21210:
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc
> -shared-libgcc
> -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++
> -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-
> gnu/32/libstdc++-v3/src
> -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-
> gnu/32/libstdc++-v3/src/.libs
> -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-
> gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/
> -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
> -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking  -m32 -o
> conftest -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions  
> conftest.cpp  >&5
> -/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/cc2GI8iw.o:conftest.cpp:
> function main: warning: the use of `tmpnam' is dangerous, better use
> `mkstemp'
> -configure:21210: $? = 0
> -configure:21226: result: yes
> +configure:21210:
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/xgcc
> -shared-libgcc
> -B/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -nostdinc++
> -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-
> gnu/32/libstdc++-v3/src
> -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-
> gnu/32/libstdc++-v3/src/.libs
> -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-
> gnu/32/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/
> -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include
> -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1  -m32 -o conftest
> -g -march=native -pipe -O2 -D_GNU_SOURCE -fno-exceptions   conftest.cpp  >&5
> +collect2: fatal error: ld terminated with signal 11 [Segmentation fault],
> core dumped
> +compilation terminated.
> +configure:21210: $? = 1

Great find! Looks like it's an `ld` crash (`ld.gold` perhaps?). If it's non-deterministic that would explain why detection of `tmpnam` (and who knows what else) flaps back and forth from stage to stage.

I suggest the following plan:
1. Verify that you can reproduce the crash by running above compiler command against source in config.log:

  """
  configure: failed program was:
  | /* confdefs.h */
  ...
  | }
  configure:21226: result: no
  """
2. If it crashes check how deterministic it is: say, run link test 10 times and see if it will crash all 10 times or not.
3. get a symbolized backtrace from crashing ld

> This is the difference between the compiler arguments:
> @@ -11,7 +11,7 @@
>  /usr/x86_64-pc-linux-gnu/include
>  -isystem
>  /usr/x86_64-pc-linux-gnu/sys-include
> --fno-checking
> +-fchecking=1
> 
> I'll attach both config.logs.

-fno-checking / -fchecking=1 ideally should not change code generation (and input to `ld` should be the same for both options).
Comment 22 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-08 12:41:37 UTC
I see a related failure when try to use gold:

$ cat a.p.c
void tmpnam(void);
void _start(void) {
  tmpnam(
# 1 ""
  );
}

$ /usr/bin/x86_64-pc-linux-gnu-gcc-11.1.0 -c -o a.o -m32 -g a.p.c
$ /usr/bin/x86_64-pc-linux-gnu-gcc-11.1.0 -o a -m32 -g a.o -fuse-ld=gold -nostdlib -lc
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: internal error in format_file_lineno, at ../../binutils-2.36.1/gold/dwarf_reader.cc:2278

Which is no a SIGSEGV, but probably a very close relative.

binutils-2.36.1's gold does not support dwarf-5 (gcc-11's default).

That was fixed only in git master: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5cde809b7b9da3ad3aa0d65f0e5e92ab199d64f0
Comment 23 Steffen Hau 2021-05-10 18:52:33 UTC
(In reply to Sergei Trofimovich from comment #21)
> Great find! Looks like it's an `ld` crash (`ld.gold` perhaps?). If it's
> non-deterministic that would explain why detection of `tmpnam` (and who
> knows what else) flaps back and forth from stage to stage.
I think it only flaps between stage 2 and 3 32 bit build. I have check other config.log file for tmpnam:

/var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage2-x86_64-pc-linux-gnu/libstdc++-v3/config.log, /var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage3-x86_64-pc-linux-gnu/libstdc++-v3/config.log
/usr/x86_64-pc-linux-gnu/bin/ld: internal error in format_file_lineno, at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:2278
collect2: error: ld returned 1 exit status

/var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage2-x86_64-pc-linux-gnu/32/libstdc++-v3/config.log
function main: warning: the use of `tmpnam' is dangerous, better use `mkstemp'

/var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage3-x86_64-pc-linux-gnu/32/libstdc++-v3/config.log:
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped

/var/tmp/portage/sys-devel/gcc-11.1.0/work/build/build-x86_64-pc-linux-gnu/libiberty/config.log,/var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage3-libiberty/config.log,
/var/tmp/portage/sys-devel/gcc-11.1.0/work/build/stage2-libiberty/config.log
function main: warning: the use of `tmpnam' is dangerous, better use `mkstemp'


> I suggest the following plan:
> 1. Verify that you can reproduce the crash by running above compiler command
> against source in config.log:
> 
>   """
>   configure: failed program was:
>   | /* confdefs.h */
>   ...
>   | }
>   configure:21226: result: no
>   """
> 2. If it crashes check how deterministic it is: say, run link test 10 times
> and see if it will crash all 10 times or not.
> 3. get a symbolized backtrace from crashing ld
I'm not able to reproduce the segfault. I'm only getting the error from ld.gold about dwarf_reader.

I have seen that coredumpctl lists the segfault from ld, so I have remerged binutils with:
CFLAGS="${CFLAGS} -ggdb"
CXXFLAGS="${CXXFLAGS} -ggdb"
FEATURES="${FEATURES} splitdebug compressdebug"

and now I'm recompiling GCC in the hope of getting a BT via coredumpctl.
Comment 24 Steffen Hau 2021-05-10 20:39:33 UTC
The segfault now occurs at other checks but the stage comparison was now successful. I will now remerge binutils without the debugging flags and check what happens if i compile gcc again.

I also have now some backtraces of the crashed ld, they look similar but I can#t see what the excat reason for the segfault was, perhaps you can do siomething with the information, here is one example:

wohnzimmernuc /tmp/gcc11 #  coredumpctl debug 2269313
           PID: 2269313 (ld)
           UID: 250 (portage)
           GID: 250 (portage)
        Signal: 11 (SEGV)
     Timestamp: Mon 2021-05-10 22:32:31 CEST (1min 23s ago)
  Command Line: /usr/x86_64-pc-linux-gnu/bin/ld -plugin /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/liblto_plugin.so -plugin-opt=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/lto-wrapper -plugin-opt=-fresolution=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccajas8M.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -o conftest /usr/lib/../lib/Scrt1.o /usr/lib/../lib/crti.o /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtbeginS.o -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc -L/usr/x86_64-pc-linux-gnu/bin -L/usr/x86_64-pc-linux-gnu/lib /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtendS.o /usr/lib/../lib/crtn.o
    Executable: /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld
 Control Group: /user.slice/user-0.slice/session-6.scope
          Unit: session-6.scope
         Slice: user-0.slice
       Session: 6
     Owner UID: 0 (root)
       Boot ID: 4de733a066a8456a97ea4e90f741b452
    Machine ID: d23c7a12b76315b709c9dae05fac8796
      Hostname: localhost
       Storage: /var/lib/systemd/coredump/core.ld.250.4de733a066a8456a97ea4e90f741b452.2269313.1620678751000000.zst (present)
     Disk Size: 334.0K
       Message: Process 2269313 (ld) of user 250 dumped core.

GNU gdb (Gentoo 10.2 vanilla) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld...
Reading symbols from /usr/lib/debug//usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld.gold.debug...

warning: Can't open file /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/32/libgfortran/conftest during file-backed mapping note processing

warning: Can't open file /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o during file-backed mapping note processing
[New LWP 319911]
Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error

warning: File "/lib64/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /lib64/libthread_db-1.0.so
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"

warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/x86_64-pc-linux-gnu/bin/ld -plugin /home/gentoo/tmp/portage/sys-devel/gcc-'.
bProgram terminated with signal SIGSEGV, Segmentation fault.
#0  0x000056422bcca71b in gold::Sized_dwarf_line_info<32, false>::process_one_opcode (this=this@entry=0x7ffc32b79af0, start=start@entry=0x81d908c9b510 <error: Cannot access memory at address 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1787
1787    /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x000056422bcca71b in gold::Sized_dwarf_line_info<32, false>::process_one_opcode (this=this@entry=0x7ffc32b79af0, start=start@entry=0x81d908c9b510 <error: Cannot access memory at address 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1787
#1  0x000056422bccb696 in gold::Sized_dwarf_line_info<32, false>::read_lines (this=this@entry=0x7ffc32b79af0, lineptr=0x81d908c9b510 <error: Cannot access memory at address 0x81d908c9b510>, shndx=shndx@entry=4294967295)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1994
#2  0x000056422bccdbe0 in gold::Sized_dwarf_line_info<32, false>::read_line_mappings (this=this@entry=0x7ffc32b79af0, shndx=shndx@entry=4294967295) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:2061
#3  0x000056422bcce01b in gold::Sized_dwarf_line_info<32, false>::Sized_dwarf_line_info (this=this@entry=0x7ffc32b79af0, object=0x56422de18490, read_shndx=read_shndx@entry=4294967295)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/dwarf_reader.cc:1630
#4  0x000056422bc1ec73 in gold::Relocate_info<32, false>::location[abi:cxx11](unsigned long, long) const (this=this@entry=0x7ffc32b79f90, offset=offset@entry=23) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/object.cc:3342
#5  0x000056422bbc144f in gold::gold_undefined_symbol_at_location<32, false> (sym=sym@entry=0x56422de3b9d0, relinfo=relinfo@entry=0x7ffc32b79f90, relnum=relnum@entry=2, reloffset=reloffset@entry=23)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/errors.cc:324
#6  0x000056422b9db595 in gold::relocate_section<32, false, (anonymous namespace)::Target_i386, (anonymous namespace)::Target_i386::Relocate, gold::Default_comdat_behavior, (anonymous namespace)::Target_i386::Classify_reloc> (reloc_symbol_changes=0x0, 
    view_size=<optimized out>, view_address=960, view=0x7f93d87a33c0 "", needs_special_offset_handling=false, output_section=0x56422dde7490, reloc_count=3, prelocs=0x7f93d9d1e614 "", target=0x56422dde6d10, relinfo=0x7ffc32b79f90)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/target-reloc.h:462
#7  (anonymous namespace)::Target_i386::relocate_section (this=0x56422dde6d10, relinfo=0x7ffc32b79f90, sh_type=<optimized out>, prelocs=<optimized out>, reloc_count=3, output_section=0x56422dde7490, needs_special_offset_handling=false, view=0x7f93d87a33c0 "", 
    address=960, view_size=<optimized out>, reloc_symbol_changes=0x0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/i386.cc:3686
#8  0x000056422bc79688 in gold::Sized_relobj_file<32, false>::relocate_section_range (this=0x56422de18490, symtab=0x7ffc32b7a630, layout=<optimized out>, pshdrs=0x7f93d9d1e7c8 "", of=0x56422df094e0, pviews=0x7ffc32b7a060, start_shndx=1, end_shndx=26)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:1005
#9  0x000056422bc79b11 in gold::Sized_relobj_file<32, false>::do_relocate_sections (this=<optimized out>, symtab=<optimized out>, layout=<optimized out>, pshdrs=<optimized out>, of=<optimized out>, pviews=<optimized out>)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:874
#10 0x000056422bc75cb3 in gold::Sized_relobj_file<32, false>::relocate_sections (pviews=0x7ffc32b7a060, of=0x56422df094e0, pshdrs=0x7f93d9d1e7c8 "", layout=0x7ffc32b7a8f0, symtab=0x7ffc32b7a630, this=0x56422de18490)
    at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/object.h:2728
#11 gold::Sized_relobj_file<32, false>::do_relocate (this=0x56422de18490, symtab=0x7ffc32b7a630, layout=0x7ffc32b7a8f0, of=0x56422df094e0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:631
#12 0x000056422bc6c19d in gold::Relobj::relocate (of=<optimized out>, layout=<optimized out>, symtab=<optimized out>, this=<optimized out>) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/object.h:1326
#13 gold::Relocate_task::run (this=0x56422df09780) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/reloc.cc:239
#14 0x000056422bcb7b68 in gold::Workqueue::find_and_run_task (this=0x7ffc32b7a330, thread_number=0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/workqueue.cc:319
#15 0x000056422bcb7e0a in gold::Workqueue::process (this=this@entry=0x7ffc32b7a330, thread_number=thread_number@entry=0) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/workqueue.cc:495
#16 0x000056422b9c2750 in main (argc=<optimized out>, argv=<optimized out>) at /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/gold/main.cc:252
(gdb) q
Comment 25 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-10 20:58:50 UTC
(In reply to Steffen Hau from comment #24)
> The segfault now occurs at other checks but the stage comparison was now
> successful. I will now remerge binutils without the debugging flags and
> check what happens if i compile gcc again.
> 
> I also have now some backtraces of the crashed ld, they look similar but I
> can#t see what the excat reason for the segfault was, perhaps you can do
> siomething with the information, here is one example:
> 
> wohnzimmernuc /tmp/gcc11 #  coredumpctl debug 2269313
>            PID: 2269313 (ld)
>            UID: 250 (portage)
>            GID: 250 (portage)
>         Signal: 11 (SEGV)
>      Timestamp: Mon 2021-05-10 22:32:31 CEST (1min 23s ago)
>   Command Line: /usr/x86_64-pc-linux-gnu/bin/ld -plugin
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/liblto_plugin.
> so
> -plugin-opt=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/
> lto-wrapper
> -plugin-opt=-fresolution=/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/
> ccajas8M.res -plugin-opt=-pass-through=-lgcc
> -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
> -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
> --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -pie -o
> conftest /usr/lib/../lib/Scrt1.o /usr/lib/../lib/crti.o
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtbeginS.
> o -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32
> -L/lib/../lib -L/usr/lib/../lib
> -L/home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc
> -L/usr/x86_64-pc-linux-gnu/bin -L/usr/x86_64-pc-linux-gnu/lib
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o -lgcc
> --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state
> --as-needed -lgcc_s --pop-state
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/./gcc/32/crtendS.o
> /usr/lib/../lib/crtn.o
>     Executable: /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld
>  Control Group: /user.slice/user-0.slice/session-6.scope
>           Unit: session-6.scope
>          Slice: user-0.slice
>        Session: 6
>      Owner UID: 0 (root)
>        Boot ID: 4de733a066a8456a97ea4e90f741b452
>     Machine ID: d23c7a12b76315b709c9dae05fac8796
>       Hostname: localhost
>        Storage:
> /var/lib/systemd/coredump/core.ld.250.4de733a066a8456a97ea4e90f741b452.
> 2269313.1620678751000000.zst (present)
>      Disk Size: 334.0K
>        Message: Process 2269313 (ld) of user 250 dumped core.
> 
> GNU gdb (Gentoo 10.2 vanilla) 10.2
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://bugs.gentoo.org/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
> 
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld...
> Reading symbols from
> /usr/lib/debug//usr/x86_64-pc-linux-gnu/binutils-bin/2.36.1/ld.gold.debug...
> 
> warning: Can't open file
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/work/build/x86_64-pc-linux-gnu/
> 32/libgfortran/conftest during file-backed mapping note processing
> 
> warning: Can't open file
> /home/gentoo/tmp/portage/sys-devel/gcc-11.1.0/temp/ccVByt4s.o during
> file-backed mapping note processing
> [New LWP 319911]
> Warning: couldn't activate thread debugging using libthread_db: Cannot find
> new threads: generic error
> 
> warning: File "/lib64/libthread_db-1.0.so" auto-loading has been declined by
> your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
> To enable execution of this file add
>         add-auto-load-safe-path /lib64/libthread_db-1.0.so
> line to your configuration file "/root/.gdbinit".
> To completely disable this security protection add
>         set auto-load safe-path /
> line to your configuration file "/root/.gdbinit".
> For more information about this security protection see the
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
> shell:
>         info "(gdb)Auto-loading safe path"
> 
> warning: Unable to find libthread_db matching inferior's thread library,
> thread debugging will not be available.
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `/usr/x86_64-pc-linux-gnu/bin/ld -plugin
> /home/gentoo/tmp/portage/sys-devel/gcc-'.
> bProgram terminated with signal SIGSEGV, Segmentation fault.
> #0  0x000056422bcca71b in gold::Sized_dwarf_line_info<32,
> false>::process_one_opcode (this=this@entry=0x7ffc32b79af0,
> start=start@entry=0x81d908c9b510 <error: Cannot access memory at address
> 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988)
>     at
> /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/
> gold/dwarf_reader.cc:1787
> 1787   
> /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/
> gold/dwarf_reader.cc: Datei oder Verzeichnis nicht gefunden.
> (gdb) bt
> #0  0x000056422bcca71b in gold::Sized_dwarf_line_info<32,
> false>::process_one_opcode (this=this@entry=0x7ffc32b79af0,
> start=start@entry=0x81d908c9b510 <error: Cannot access memory at address
> 0x81d908c9b510>, lsm=lsm@entry=0x7ffc32b799b0, len=len@entry=0x7ffc32b79988)
>     at
> /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/
> gold/dwarf_reader.cc:1787
> #1  0x000056422bccb696 in gold::Sized_dwarf_line_info<32, false>::read_lines
> (this=this@entry=0x7ffc32b79af0, lineptr=0x81d908c9b510 <error: Cannot
> access memory at address 0x81d908c9b510>, shndx=shndx@entry=4294967295)
>     at
> /home/gentoo/tmp/portage/sys-devel/binutils-2.36.1-r1/work/binutils-2.36.1/
> gold/dwarf_reader.cc:1994
> #2  0x000056422bccdbe0 in gold::Sized_dwarf_line_info<32,

Aha, the crash also stems from the inability to parse dwarf-5. I guess crash is very dependent in exact input and sometimes happens to work (as opposed to always crash).

That makes Gentoo's gold incomatible with gcc-11. We will need a new gold. As a workaround you might need to switch to ld.bfd, or to gcc-10 or to CFLAGS/CXXFLAGS/LDFLAGS=-gdwarf-4.
Comment 26 Steffen Hau 2021-05-15 22:05:51 UTC
(In reply to Sergei Trofimovich from comment #25)
> Aha, the crash also stems from the inability to parse dwarf-5. I guess crash
> is very dependent in exact input and sometimes happens to work (as opposed
> to always crash).
> 
> That makes Gentoo's gold incomatible with gcc-11. We will need a new gold.
> As a workaround you might need to switch to ld.bfd, or to gcc-10 or to
> CFLAGS/CXXFLAGS/LDFLAGS=-gdwarf-4.
Would it be possible to backport the patch you mentioned in comment 22 to binutils-2.36.1?
Comment 27 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-16 10:00:22 UTC
(In reply to Steffen Hau from comment #26)
> Would it be possible to backport the patch you mentioned in comment 22 to
> binutils-2.36.1?

I would prefer not to. There are a few patches and they are quite big.
Comment 28 tt_1 2021-05-17 10:54:29 UTC
(In reply to Sergei Trofimovich from comment #27)
> (In reply to Steffen Hau from comment #26)
> > Would it be possible to backport the patch you mentioned in comment 22 to
> > binutils-2.36.1?
> 
> I would prefer not to. There are a few patches and they are quite big.

so the to be released binutils-2.37.x would be the one with the fixes included?
Comment 29 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-17 19:07:18 UTC
That's perhaps a question that upstream will be best to answer.
Comment 30 tt_1 2021-07-22 10:45:05 UTC
seems as if sys-devel/binutils-2.37 has the patch included
Comment 31 Andreas K. Hüttel archtester gentoo-dev 2021-10-09 16:32:05 UTC
(In reply to tt_1 from comment #30)
> seems as if sys-devel/binutils-2.37 has the patch included

yes, and most dwarf5 support should also be in 2.36.1-r2 via the binutils stable branch.