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
Created attachment 706434 [details] build.log
- try vanilla CFLAGS? Any difference? - what about if you disable gold?
(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.
(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.
Please attach one diffing object file from stage2 and stage3 for comparison.
Created attachment 706470 [details] gcc differing objects between stage 2 and 3
(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?
(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.
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
(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 -
(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.
Created attachment 706560 [details] gcc-11-unstable-bug-788661.tar.gz
./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.
(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).
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
(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.
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
> > $ 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.
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.
Created attachment 706617 [details] libstdc++ stage{2,3} config.log
(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).
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
(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.
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
(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.
(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?
(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.
(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?
That's perhaps a question that upstream will be best to answer.
seems as if sys-devel/binutils-2.37 has the patch included
(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.
These older versions are masked.
