|
Description
Furude Rika
2020-05-20 09:56:58 UTC
Created attachment 640550 [details]
Build Log
Build log generated when it built failed
Portage 2.3.99 (python 3.7.7-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-10.1.0, glibc-2.31-r3, 5.6.13-gentoo x86_64)
=================================================================
System uname: Linux-5.6.13-gentoo-x86_64-AMD_Ryzen_5_1600_Six-Core_Processor-with-gentoo-2.7
KiB Mem: 8164568 total, 3929688 free
KiB Swap: 8388604 total, 8388604 free
Timestamp of repository gentoo: Wed, 20 May 2020 02:15:01 +0000
Head commit of repository gentoo: cf95a138451d35566712e45ae763c0470ea2254e
sh bash 5.0_p17
ld GNU ld (Gentoo 2.34 p4) 2.34.0
app-shells/bash: 5.0_p17::gentoo
dev-lang/perl: 5.30.2-r2::gentoo
dev-lang/python: 2.7.18::gentoo, 3.7.7-r2::gentoo, 3.8.3::gentoo
dev-util/cmake: 3.17.2::gentoo
sys-apps/baselayout: 2.7::gentoo
sys-apps/openrc: 0.42.1::gentoo
sys-apps/sandbox: 2.18::gentoo
sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake: 1.16.2::gentoo
sys-devel/binutils: 2.34-r1::gentoo
sys-devel/gcc: 10.1.0::gentoo
sys-devel/gcc-config: 2.2.1::gentoo
sys-devel/libtool: 2.4.6-r6::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.6::gentoo (virtual/os-headers)
sys-libs/glibc: 2.31-r3::gentoo
Repositories:
gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://mirrors.tuna.tsinghua.edu.cn/gentoo-portage
priority: -1000
sync-rsync-verify-metamanifest: yes
sync-rsync-extra-opts:
sync-rsync-verify-max-age: 24
sync-rsync-verify-jobs: 1
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O3 -pipe -march=native"
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="-O3 -pipe -march=native"
DISTDIR="/var/cache/distfiles"
EMERGE_DEFAULT_OPTS="--ask"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN 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="-O3 -pipe -march=native"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch 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="-O3 -pipe -march=native"
GENTOO_MIRRORS="https://mirrors.tuna.tsinghua.edu.cn/gentoo"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j6"
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="/var/tmp"
USE="X a52 aac acl acpi activities alsa amd64 berkdb branding bzip2 cairo cdda cdr cli crypt cups dbus declarative dri dts dvd dvdr elogind emboss encode exif flac fortran gdbm gif gpm gtk iconv icu ipv6 jpeg kde kipi kwallet lcms ldap libnotify libtirpc mad mng mp3 mp4 mpeg multilib ncurses nls nptl ogg opengl openmp pam pango pcre pdf phonon plasma png policykit ppds qml qt5 readline sdl seccomp semantic-desktop spell split-usr ssl startup-notification svg tcpd tiff truetype udev udisks unicode upower usb vorbis widgets wxwidgets x264 xattr xcb xml xv xvid zlib" ABI_X86="64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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="mmx mmxext sse sse2" 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" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-2" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python2_7 python3_7" RUBY_TARGETS="ruby24 ruby25" USERLAND="GNU" VIDEO_CARDS="amdgpu radeonsi" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Paging in slyfox, who might be able to help, given that this is an ICE. """
"x86_64-pc-linux-gnu-g++" -fvisibility-inlines-hidden -O3 -pipe -march=native -std=c++14 -fPIC -m64 -pthread -finline-functions -Wno-inline -
Wall -fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1
-DNDEBUG -I"." -c -o "bin.v2/libs/serialization/build/gcc-10.1/gentoorelease/pch-off/threading-multi/visibility-hidden/xml_grammar.o" "libs/seria
lization/src/xml_grammar.cpp"
*** stack smashing detected ***: terminated
In file included from libs/serialization/src/xml_grammar.cpp:64:
libs/serialization/src/basic_xml_grammar.ipp: In constructor ‘boost::archive::basic_xml_grammar<CharType>::basic_xml_grammar() [with CharType = cha
r]’:
libs/serialization/src/basic_xml_grammar.ipp:406:9: internal compiler error: Aborted
402 | !S
| ~~
403 | >> str_p(L"<?xml")
| ~~~~~~~~~~~~~~~~~~
404 | >> S
| ~~~~
405 | >> str_p(L"version")
| ~~~~~~~~~~~~~~~~~~~~
406 | >> Eq
| ^~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
"""
Yeah, looks like a toolchain bug. I'll try to reproduce locally.
Meanwhile, myloveyuxuan@gmail.com, can you follow https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide to extract preprocessed file and expand -march=native?
(In reply to Sergei Trofimovich from comment #4) > I'll try to reproduce locally. I was not able to reproduce locally in an -O3 -march=native chroot. That probably means that gcc itself was mis-compiled for your target. Try to get a symbolized gcc backtrace when if smashes it's sack. https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces should help in that. The following options are target specific:
-m128bit-long-double [disabled]
-m16 [disabled]
-m32 [disabled]
-m3dnow [disabled]
-m3dnowa [disabled]
-m64 [enabled]
-m80387 [enabled]
-m8bit-idiv [disabled]
-m96bit-long-double [enabled]
-mabi= sysv
-mabm [disabled]
-maccumulate-outgoing-args [disabled]
-maddress-mode= short
-madx [disabled]
-maes [disabled]
-malign-data= compat
-malign-double [disabled]
-malign-functions= 0
-malign-jumps= 0
-malign-loops= 0
-malign-stringops [enabled]
-mandroid [disabled]
-march= x86-64
-masm= att
-mavx [disabled]
-mavx2 [disabled]
-mavx256-split-unaligned-load [disabled]
-mavx256-split-unaligned-store [disabled]
-mavx5124fmaps [disabled]
-mavx5124vnniw [disabled]
-mavx512bf16 [disabled]
-mavx512bitalg [disabled]
-mavx512bw [disabled]
-mavx512cd [disabled]
-mavx512dq [disabled]
-mavx512er [disabled]
-mavx512f [disabled]
-mavx512ifma [disabled]
-mavx512pf [disabled]
-mavx512vbmi [disabled]
-mavx512vbmi2 [disabled]
-mavx512vl [disabled]
-mavx512vnni [disabled]
-mavx512vp2intersect [disabled]
-mavx512vpopcntdq [disabled]
-mbionic [disabled]
-mbmi [disabled]
-mbmi2 [disabled]
-mbranch-cost=<0,5> 0
-mcall-ms2sysv-xlogues [disabled]
-mcet-switch [disabled]
-mcld [disabled]
-mcldemote [disabled]
-mclflushopt [disabled]
-mclwb [disabled]
-mclzero [disabled]
-mcmodel= 32
-mcpu=
-mcrc32 [disabled]
-mcx16 [disabled]
-mdispatch-scheduler [disabled]
-mdump-tune-features [disabled]
-menqcmd [disabled]
-mf16c [disabled]
-mfancy-math-387 [enabled]
-mfentry [disabled]
-mfentry-name=
-mfentry-section=
-mfma [disabled]
-mfma4 [disabled]
-mforce-drap [disabled]
-mforce-indirect-call [disabled]
-mfp-ret-in-387 [enabled]
-mfpmath= 387
-mfsgsbase [disabled]
-mfunction-return= keep
-mfused-madd -ffp-contract=fast
-mfxsr [disabled]
-mgeneral-regs-only [disabled]
-mgfni [disabled]
-mglibc [enabled]
-mhard-float [enabled]
-mhle [disabled]
-miamcu [disabled]
-mieee-fp [enabled]
-mincoming-stack-boundary= 0
-mindirect-branch-register [disabled]
-mindirect-branch= keep
-minline-all-stringops [disabled]
-minline-stringops-dynamically [disabled]
-minstrument-return= none
-mintel-syntax -masm=intel
-mlarge-data-threshold=<number> 65536
-mlong-double-128 [disabled]
-mlong-double-64 [disabled]
-mlong-double-80 [enabled]
-mlwp [disabled]
-mlzcnt [disabled]
-mmanual-endbr [disabled]
-mmemcpy-strategy=
-mmemset-strategy=
-mmitigate-rop [disabled]
-mmmx [disabled]
-mmovbe [disabled]
-mmovdir64b [disabled]
-mmovdiri [disabled]
-mmpx [disabled]
-mms-bitfields [disabled]
-mmusl [disabled]
-mmwaitx [disabled]
-mno-align-stringops [disabled]
-mno-default [disabled]
-mno-fancy-math-387 [disabled]
-mno-push-args [disabled]
-mno-red-zone [disabled]
-mno-sse4 [enabled]
-mnop-mcount [disabled]
-momit-leaf-frame-pointer [disabled]
-mpc32 [disabled]
-mpc64 [disabled]
-mpc80 [disabled]
-mpclmul [disabled]
-mpcommit [disabled]
-mpconfig [disabled]
-mpku [disabled]
-mpopcnt [disabled]
-mprefer-avx128 -mprefer-vector-width=128
-mprefer-vector-width= none
-mpreferred-stack-boundary= 0
-mprefetchwt1 [disabled]
-mprfchw [disabled]
-mptwrite [disabled]
-mpush-args [enabled]
-mrdpid [disabled]
-mrdrnd [disabled]
-mrdseed [disabled]
-mrecip [disabled]
-mrecip=
-mrecord-mcount [disabled]
-mrecord-return [disabled]
-mred-zone [enabled]
-mregparm= 0
-mrtd [disabled]
-mrtm [disabled]
-msahf [disabled]
-msgx [disabled]
-msha [disabled]
-mshstk [disabled]
-mskip-rax-setup [disabled]
-msoft-float [disabled]
-msse [disabled]
-msse2 [disabled]
-msse2avx [disabled]
-msse3 [disabled]
-msse4 [disabled]
-msse4.1 [disabled]
-msse4.2 [disabled]
-msse4a [disabled]
-msse5 -mavx
-msseregparm [disabled]
-mssse3 [disabled]
-mstack-arg-probe [disabled]
-mstack-protector-guard-offset=
-mstack-protector-guard-reg=
-mstack-protector-guard-symbol=
-mstack-protector-guard= tls
-mstackrealign [disabled]
-mstringop-strategy= [default]
-mstv [disabled]
-mtbm [disabled]
-mtls-dialect= gnu
-mtls-direct-seg-refs [enabled]
-mtune-ctrl=
-mtune= generic
-muclibc [disabled]
-mvaes [disabled]
-mveclibabi= [default]
-mvect8-ret-in-mem [disabled]
-mvpclmulqdq [disabled]
-mvzeroupper [disabled]
-mwaitpkg [disabled]
-mwbnoinvd [disabled]
-mx32 [disabled]
-mxop [disabled]
-mxsave [disabled]
-mxsavec [disabled]
-mxsaveopt [disabled]
-mxsaves [disabled]
Known assembler dialects (for use with the -masm= option):
att intel
Known ABIs (for use with the -mabi= option):
ms sysv
Known code models (for use with the -mcmodel= option):
32 kernel large medium small
Valid arguments to -mfpmath=:
387 387+sse 387,sse both sse sse+387 sse,387
Known indirect branch choices (for use with the -mindirect-branch=/-mfunction-return= options):
keep thunk thunk-extern thunk-inline
Known choices for return instrumentation with -minstrument-return=:
call none nop5
Known data alignment choices (for use with the -malign-data= option):
abi cacheline compat
Known vectorization library ABIs (for use with the -mveclibabi= option):
acml svml
Known address mode (for use with the -maddress-mode= option):
long short
Known preferred register vector length (to use with the -mprefer-vector-width= option):
128 256 512 none
Known stack protector guard (for use with the -mstack-protector-guard= option):
global tls
Valid arguments to -mstringop-strategy=:
byte_loop libcall loop rep_4byte rep_8byte rep_byte unrolled_loop vector_loop
Known TLS dialects (for use with the -mtls-dialect= option):
gnu gnu2
Known valid arguments for -march= option:
i386 i486 i586 pentium lakemont pentium-mmx winchip-c6 winchip2 c3 samuel-2 c3-2 nehemiah c7 esther i686 pentiumpro pentium2 pentium3 pentium3m pentium-m pentium4 pentium4m prescott nocona core2 nehalem corei7 westmere sandybridge corei7-avx ivybridge core-avx-i haswell core-avx2 broadwell skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake tigerlake cooperlake bonnell atom silvermont slm goldmont goldmont-plus tremont knl knm intel geode k6 k6-2 k6-3 athlon athlon-tbird athlon-4 athlon-xp athlon-mp x86-64 eden-x2 nano nano-1000 nano-2000 nano-3000 nano-x2 eden-x4 nano-x4 k8 k8-sse3 opteron opteron-sse3 athlon64 athlon64-sse3 athlon-fx amdfam10 barcelona bdver1 bdver2 bdver3 bdver4 znver1 znver2 btver1 btver2 generic native
Known valid arguments for -mtune= option:
generic i386 i486 pentium lakemont pentiumpro pentium4 nocona core2 nehalem sandybridge haswell bonnell silvermont goldmont goldmont-plus tremont knl knm skylake skylake-avx512 cannonlake icelake-client icelake-server cascadelake tigerlake cooperlake intel geode k6 athlon k8 amdfam10 bdver1 bdver2 bdver3 bdver4 btver1 btver2 znver1 znver2
--- default.opts 2020-06-09 05:24:52.653429794 +0800 +++ native.opts 2020-06-09 05:24:58.589430204 +0800 @@ -12 +12 @@ - -mabm [disabled] + -mabm [enabled] @@ -15,2 +15,2 @@ - -madx [disabled] - -maes [disabled] + -madx [enabled] + -maes [enabled] @@ -24 +24 @@ - -march= x86-64 + -march= znver1 @@ -26,2 +26,2 @@ - -mavx [disabled] - -mavx2 [disabled] + -mavx [enabled] + -mavx2 [enabled] @@ -48,2 +48,2 @@ - -mbmi [disabled] - -mbmi2 [disabled] + -mbmi [enabled] + -mbmi2 [enabled] @@ -55 +55 @@ - -mclflushopt [disabled] + -mclflushopt [enabled] @@ -57 +57 @@ - -mclzero [disabled] + -mclzero [enabled] @@ -61 +61 @@ - -mcx16 [disabled] + -mcx16 [enabled] @@ -65 +65 @@ - -mf16c [disabled] + -mf16c [enabled] @@ -70 +70 @@ - -mfma [disabled] + -mfma [enabled] @@ -76 +76 @@ - -mfsgsbase [disabled] + -mfsgsbase [enabled] @@ -79 +79 @@ - -mfxsr [disabled] + -mfxsr [enabled] @@ -99 +99 @@ - -mlzcnt [disabled] + -mlzcnt [enabled] @@ -104,2 +104,2 @@ - -mmmx [disabled] - -mmovbe [disabled] + -mmmx [enabled] + -mmovbe [enabled] @@ -111 +111 @@ - -mmwaitx [disabled] + -mmwaitx [enabled] @@ -117 +117 @@ - -mno-sse4 [enabled] + -mno-sse4 [disabled] @@ -123 +123 @@ - -mpclmul [disabled] + -mpclmul [enabled] @@ -127 +127 @@ - -mpopcnt [disabled] + -mpopcnt [enabled] @@ -132 +132 @@ - -mprfchw [disabled] + -mprfchw [enabled] @@ -136,2 +136,2 @@ - -mrdrnd [disabled] - -mrdseed [disabled] + -mrdrnd [enabled] + -mrdseed [enabled] @@ -146 +146 @@ - -msahf [disabled] + -msahf [enabled] @@ -148 +148 @@ - -msha [disabled] + -msha [enabled] @@ -152,2 +152,2 @@ - -msse [disabled] - -msse2 [disabled] + -msse [enabled] + -msse2 [enabled] @@ -155,5 +155,5 @@ - -msse3 [disabled] - -msse4 [disabled] - -msse4.1 [disabled] - -msse4.2 [disabled] - -msse4a [disabled] + -msse3 [enabled] + -msse4 [enabled] + -msse4.1 [enabled] + -msse4.2 [enabled] + -msse4a [enabled] @@ -162 +162 @@ - -mssse3 [disabled] + -mssse3 [enabled] @@ -175 +175 @@ - -mtune= generic + -mtune= znver1 @@ -186,4 +186,4 @@ - -mxsave [disabled] - -mxsavec [disabled] - -mxsaveopt [disabled] - -mxsaves [disabled] + -mxsave [enabled] + -mxsavec [enabled] + -mxsaveopt [enabled] + -mxsaves [enabled] The following options control optimizations: -O<number> -Ofast -Og -Os -faggressive-loop-optimizations [enabled] -falign-functions [enabled] -falign-functions= -falign-jumps [enabled] -falign-jumps= -falign-labels [enabled] -falign-labels= -falign-loops [enabled] -falign-loops= -fallocation-dce [enabled] -fallow-store-data-races [disabled] -fassociative-math [disabled] -fassume-phsa [available in BRIG] -fasynchronous-unwind-tables [enabled] -fauto-inc-dec [enabled] -fbranch-count-reg [enabled] -fbranch-probabilities [disabled] -fcaller-saves [enabled] -fcode-hoisting [enabled] -fcombine-stack-adjustments [enabled] -fcompare-elim [enabled] -fconserve-stack [disabled] -fcprop-registers [enabled] -fcrossjumping [enabled] -fcse-follow-jumps [enabled] -fcx-fortran-rules [disabled] -fcx-limited-range [disabled] -fdce [enabled] -fdefer-pop [enabled] -fdelayed-branch [disabled] -fdelete-dead-exceptions [disabled] -fdelete-null-pointer-checks [enabled] -fdevirtualize [enabled] -fdevirtualize-speculatively [enabled] -fdse [enabled] -fearly-inlining [enabled] -fexceptions [disabled] -fexcess-precision=[fast|standard] [default] -fexpensive-optimizations [enabled] -ffast-math -ffinite-loops [disabled] -ffinite-math-only [disabled] -ffloat-store [disabled] -fforward-propagate [enabled] -ffp-contract=[off|on|fast] fast -ffp-int-builtin-inexact [enabled] -ffunction-cse [enabled] -fgcse [enabled] -fgcse-after-reload [enabled] -fgcse-las [disabled] -fgcse-lm [enabled] -fgcse-sm [disabled] -fgraphite [disabled] -fgraphite-identity [disabled] -fguess-branch-probability [enabled] -fhandle-exceptions -fexceptions -fhoist-adjacent-loads [enabled] -fif-conversion [enabled] -fif-conversion2 [enabled] -findirect-inlining [enabled] -finline [enabled] -finline-atomics [enabled] -finline-functions [enabled] -finline-functions-called-once [enabled] -finline-small-functions [enabled] -fipa-bit-cp [enabled] -fipa-cp [enabled] -fipa-cp-clone [enabled] -fipa-icf [enabled] -fipa-icf-functions [enabled] -fipa-icf-variables [enabled] -fipa-profile [enabled] -fipa-pta [disabled] -fipa-pure-const [enabled] -fipa-ra [enabled] -fipa-reference [enabled] -fipa-reference-addressable [enabled] -fipa-sra [enabled] -fipa-stack-alignment [enabled] -fipa-vrp [enabled] -fira-algorithm=[CB|priority] CB -fira-hoist-pressure [enabled] -fira-loop-pressure [disabled] -fira-region=[one|all|mixed] [default] -fira-share-save-slots [enabled] -fira-share-spill-slots [enabled] -fisolate-erroneous-paths-attribute [disabled] -fisolate-erroneous-paths-dereference [enabled] -fivopts [enabled] -fjump-tables [enabled] -fkeep-gc-roots-live [disabled] -flifetime-dse [enabled] -flifetime-dse=<0,2> 2 -flimit-function-alignment [disabled] -flive-patching -flive-patching=inline-clone -flive-patching=[inline-only-static|inline-clone] [default] -flive-range-shrinkage [disabled] -floop-interchange [enabled] -floop-nest-optimize [disabled] -floop-parallelize-all [disabled] -floop-unroll-and-jam [enabled] -flra-remat [enabled] -fmath-errno [enabled] -fmodulo-sched [disabled] -fmodulo-sched-allow-regmoves [disabled] -fmove-loop-invariants [enabled] -fnon-call-exceptions [disabled] -fnothrow-opt [available in C++, ObjC++] -fomit-frame-pointer [enabled] -fopt-info [disabled] -foptimize-sibling-calls [enabled] -foptimize-strlen [enabled] -fpack-struct [disabled] -fpack-struct=<number> -fpartial-inlining [enabled] -fpatchable-function-entry= -fpeel-loops [enabled] -fpeephole [enabled] -fpeephole2 [enabled] -fplt [enabled] -fpredictive-commoning [enabled] -fprefetch-loop-arrays [enabled] -fprintf-return-value [enabled] -fprofile-partial-training [disabled] -fprofile-reorder-functions [disabled] -freciprocal-math [disabled] -free [enabled] -freg-struct-return [disabled] -frename-registers [enabled] -freorder-blocks [enabled] -freorder-blocks-algorithm=[simple|stc] stc -freorder-blocks-and-partition [enabled] -freorder-functions [enabled] -frerun-cse-after-loop [enabled] -freschedule-modulo-scheduled-loops [disabled] -frounding-math [disabled] -frtti [available in C++, D, ObjC++] -fsave-optimization-record [disabled] -fsched-critical-path-heuristic [enabled] -fsched-dep-count-heuristic [enabled] -fsched-group-heuristic [enabled] -fsched-interblock [enabled] -fsched-last-insn-heuristic [enabled] -fsched-pressure [disabled] -fsched-rank-heuristic [enabled] -fsched-spec [enabled] -fsched-spec-insn-heuristic [enabled] -fsched-spec-load [disabled] -fsched-spec-load-dangerous [disabled] -fsched-stalled-insns [disabled] -fsched-stalled-insns-dep [enabled] -fsched-stalled-insns-dep=<number> -fsched-stalled-insns=<number> -fsched2-use-superblocks [disabled] -fschedule-fusion [enabled] -fschedule-insns [disabled] -fschedule-insns2 [enabled] -fsection-anchors [disabled] -fsel-sched-pipelining [disabled] -fsel-sched-pipelining-outer-loops [disabled] -fsel-sched-reschedule-pipelined [disabled] -fselective-scheduling [disabled] -fselective-scheduling2 [disabled] -fshort-enums [enabled] -fshort-wchar [disabled] -fshrink-wrap [enabled] -fshrink-wrap-separate [enabled] -fsignaling-nans [disabled] -fsigned-zeros [enabled] -fsimd-cost-model=[unlimited|dynamic|cheap] unlimited -fsingle-precision-constant [disabled] -fsplit-ivs-in-unroller [enabled] -fsplit-loops [enabled] -fsplit-paths [enabled] -fsplit-wide-types [enabled] -fsplit-wide-types-early [disabled] -fssa-backprop [enabled] -fssa-phiopt [enabled] -fstack-check=[no|generic|specific] -fstack-clash-protection [enabled] -fstack-protector [disabled] -fstack-protector-all [disabled] -fstack-protector-explicit [disabled] -fstack-protector-strong [enabled] -fstack-reuse=[all|named_vars|none] all -fstdarg-opt [enabled] -fstore-merging [enabled] -fstrict-aliasing [enabled] -fstrict-enums [available in C++, ObjC++] -fstrict-volatile-bitfields [enabled] -fthread-jumps [enabled] -fno-threadsafe-statics [available in C++, ObjC++] -ftoplevel-reorder [enabled] -ftracer [disabled] -ftrapping-math [enabled] -ftrapv [disabled] -ftree-bit-ccp [enabled] -ftree-builtin-call-dce [enabled] -ftree-ccp [enabled] -ftree-ch [enabled] -ftree-coalesce-vars [enabled] -ftree-copy-prop [enabled] -ftree-cselim [enabled] -ftree-dce [enabled] -ftree-dominator-opts [enabled] -ftree-dse [enabled] -ftree-forwprop [enabled] -ftree-fre [enabled] -ftree-loop-distribute-patterns [enabled] -ftree-loop-distribution [enabled] -ftree-loop-if-convert [enabled] -ftree-loop-im [enabled] -ftree-loop-ivcanon [enabled] -ftree-loop-optimize [enabled] -ftree-loop-vectorize [enabled] -ftree-lrs [disabled] -ftree-parallelize-loops=<number> 1 -ftree-partial-pre [enabled] -ftree-phiprop [enabled] -ftree-pre [enabled] -ftree-pta [enabled] -ftree-reassoc [enabled] -ftree-scev-cprop [enabled] -ftree-sink [enabled] -ftree-slp-vectorize [enabled] -ftree-slsr [enabled] -ftree-sra [enabled] -ftree-switch-conversion [enabled] -ftree-tail-merge [enabled] -ftree-ter [enabled] -ftree-vectorize -ftree-vrp [enabled] -funconstrained-commons [disabled] -funroll-all-loops [disabled] -funroll-loops [disabled] -funsafe-math-optimizations [disabled] -funswitch-loops [enabled] -funwind-tables [disabled] -fvar-tracking [enabled] -fvar-tracking-assignments [enabled] -fvar-tracking-assignments-toggle [disabled] -fvar-tracking-uninit [disabled] -fvariable-expansion-in-unroller [disabled] -fvect-cost-model=[unlimited|dynamic|cheap] dynamic -fversion-loops-for-strides [enabled] -fvpt [disabled] -fweb [enabled] -fwrapv [disabled] -fwrapv-pointer [disabled] --- O2.opts 2020-06-09 05:26:53.908438157 +0800 +++ O3.opts 2020-06-09 05:27:00.732438628 +0800 @@ -54 +54 @@ - -fgcse-after-reload [disabled] + -fgcse-after-reload [enabled] @@ -73 +73 @@ - -fipa-cp-clone [disabled] + -fipa-cp-clone [enabled] @@ -103 +103 @@ - -floop-interchange [disabled] + -floop-interchange [enabled] @@ -106 +106 @@ - -floop-unroll-and-jam [disabled] + -floop-unroll-and-jam [enabled] @@ -122 +122 @@ - -fpeel-loops [disabled] + -fpeel-loops [enabled] @@ -126 +126 @@ - -fpredictive-commoning [disabled] + -fpredictive-commoning [enabled] @@ -178,2 +178,2 @@ - -fsplit-loops [disabled] - -fsplit-paths [disabled] + -fsplit-loops [enabled] + -fsplit-paths [enabled] @@ -215 +215 @@ - -ftree-loop-distribution [disabled] + -ftree-loop-distribution [enabled] @@ -220 +220 @@ - -ftree-loop-vectorize [disabled] + -ftree-loop-vectorize [enabled] @@ -223 +223 @@ - -ftree-partial-pre [disabled] + -ftree-partial-pre [enabled] @@ -230 +230 @@ - -ftree-slp-vectorize [disabled] + -ftree-slp-vectorize [enabled] @@ -242 +242 @@ - -funswitch-loops [disabled] + -funswitch-loops [enabled] @@ -249,2 +249,2 @@ - -fvect-cost-model=[unlimited|dynamic|cheap] cheap - -fversion-loops-for-strides [disabled] + -fvect-cost-model=[unlimited|dynamic|cheap] dynamic + -fversion-loops-for-strides [enabled] Currently logging to "gdb.txt". Logs will be appended to the log file. Output will be logged and displayed. Debug output will be logged and displayed. Function "internal_error" not defined. Breakpoint 1 (internal_error) pending. Starting program: /usr/bin/x86_64-pc-linux-gnu-g++ -fvisibility-inlines-hidden -O3 -march=native -pipe -std=c++14 -fPIC -m64 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I. -c -o bin.v2/libs/serialization/build/gcc-10.1/gentoorelease/pch-off/threading-multi/visibility-hidden/xml_grammar.o libs/serialization/src/xml_grammar.cpp [Attaching after process 31746 vfork to child process 31750] [New inferior 2 (process 31750)] [Detaching vfork parent process 31746 after child exec] [Inferior 1 (process 31746) detached] process 31750 is executing new program: /usr/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/cc1plus Thread 2.1 "cc1plus" received signal SIGABRT, Aborted. [Switching to process 31750] 0x00007ffff7bc39a1 in raise () from /lib64/libc.so.6 #0 0x00007ffff7bc39a1 in raise () from /lib64/libc.so.6 #1 0x00007ffff7bad53b in abort () from /lib64/libc.so.6 #2 0x00007ffff7c07ae7 in ?? () from /lib64/libc.so.6 #3 0x00007ffff7c98e12 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007ffff7c98df0 in __stack_chk_fail () from /lib64/libc.so.6 #5 0x000000000065a1f2 in cp_gimplify_expr(tree_node**, gimple**, gimple**) () #6 0x00000000009f505c in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #7 0x00000000009fe351 in ?? () #8 0x00000000009f63b0 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #9 0x00000000009fb6b1 in ?? () #10 0x00000000009f5fcf in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #11 0x00000000009fbad5 in ?? () #12 0x00000000009fc456 in ?? () #13 0x00000000009f63d3 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #14 0x00000000009faf11 in ?? () #15 0x00000000009f6364 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #16 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #17 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #18 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #19 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #20 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #21 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #22 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #23 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #24 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #25 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #26 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #27 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #28 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #29 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #30 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #31 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #32 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #33 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #34 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #35 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #36 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #37 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #38 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #39 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #40 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #41 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #42 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #43 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #44 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #45 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #46 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #47 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #48 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #49 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #50 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #51 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #52 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #53 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #54 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #55 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #56 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #57 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #58 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #59 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #60 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #61 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #62 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #63 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #64 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #65 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #66 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #67 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #68 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #69 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #70 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #71 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #72 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #73 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #74 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #75 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #76 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #77 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #78 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #79 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #80 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #81 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #82 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #83 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #84 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #85 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #86 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #87 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #88 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #89 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #90 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #91 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #92 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #93 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #94 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #95 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #96 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #97 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #98 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #99 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #100 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #101 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #102 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #103 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #104 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #105 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #106 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #107 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #108 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #109 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #110 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #111 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #112 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #113 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #114 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #115 0x00000000009f5da2 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #116 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #117 0x00000000009fd619 in ?? () #118 0x00000000009f63ed in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #119 0x00000000009f61f6 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #120 0x00000000009f9f39 in gimplify_body(tree_node*, bool) () #121 0x00000000009fa376 in gimplify_function_tree(tree_node*) () #122 0x0000000000885f98 in cgraph_node::analyze() () #123 0x00000000008888b8 in ?? () #124 0x0000000000889503 in symbol_table::finalize_compilation_unit() () #125 0x0000000000c76a41 in ?? () #126 0x000000000060065a in toplev::main(int, char**) () #127 0x000000000060413c in main () Created attachment 643972 [details]
preprocessed file of xml_grammar.c
(In reply to Sergei Trofimovich from comment #5) > (In reply to Sergei Trofimovich from comment #4) > > I'll try to reproduce locally. > > > I was not able to reproduce locally in an -O3 -march=native chroot. That > probably means that gcc itself was mis-compiled for your target. Try to get > a symbolized gcc backtrace when if smashes it's sack. > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces should > help in that. Sure I can. Here is the summary of the more information added in the new comment. Comment 6 is the output of command `LANG=C gcc -Q --help=target` Comment 7 is the differences between the output of the command `LANG=C gcc -Q --help=target` and the command `LANG=C gcc -march=native -Q --help=target` Comment 8 is the output of command `LANG=C gcc -march=native -O3 -Q --help=optimizers` Comment 9 is the differences between the output of the command `LANG=C gcc -march=native -O3 -Q --help=optimizers` and the command `LANG=C gcc -march=native -O2 -Q --help=optimizers` Comment 10 is the symbolized gcc backtrace when smashes it's stack. And the attachment in the Comment 11 is preprocessed file of xml_grammer.c (In reply to myloveyuxuan from comment #12) > (In reply to Sergei Trofimovich from comment #5) > > (In reply to Sergei Trofimovich from comment #4) > > > I'll try to reproduce locally. > > > > > > I was not able to reproduce locally in an -O3 -march=native chroot. That > > probably means that gcc itself was mis-compiled for your target. Try to get > > a symbolized gcc backtrace when if smashes it's sack. > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces should > > help in that. > > Sure I can. > > Here is the summary of the more information added in the new comment. > > Comment 6 is the output of command `LANG=C gcc -Q --help=target` > > Comment 7 is the differences between the output of the command `LANG=C gcc > -Q --help=target` and the command `LANG=C gcc -march=native -Q --help=target` > > Comment 8 is the output of command `LANG=C gcc -march=native -O3 -Q > --help=optimizers` > > Comment 9 is the differences between the output of the command `LANG=C gcc > -march=native -O3 -Q --help=optimizers` and the command `LANG=C gcc > -march=native -O2 -Q --help=optimizers` > > Comment 10 is the symbolized gcc backtrace when smashes it's stack. Looks like it does not have line numbers attached. Usually extra debug info can be obtained if compiled with -g (or -ggdb) added to CFLAGS/CXXFLAGS. > And the attachment in the Comment 11 is preprocessed file of xml_grammer.c Just to clarify: you see the crash if you run gcc on a preprocessed file as well, right? Thank you! Created attachment 644126 [details]
The preprocessed file of xml_grammar.cpp
The output of ` "x86_64-pc-linux-gnu-g++" -fvisibility-inlines-hidden -O3 -march=native -pipe -std=c++14 -fPIC -m64 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -E libs/serialization/src/xml_grammar.cpp`
Function "internal_error" not defined. Breakpoint 1 (internal_error) pending. Starting program: /usr/bin/x86_64-pc-linux-gnu-g++ -fvisibility-inlines-hidden -O3 -march=native -pipe -std=c++14 -fPIC -m64 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I. -c -o bin.v2/libs/serialization/build/gcc-10.1/gentoorelease/pch-off/threading-multi/visibility-hidden/xml_grammar.o libs/serialization/src/xml_grammar.cpp [Attaching after process 15907 vfork to child process 15911] [New inferior 2 (process 15911)] [Detaching vfork parent process 15907 after child exec] [Inferior 1 (process 15907) detached] process 15911 is executing new program: /usr/libexec/gcc/x86_64-pc-linux-gnu/10.1.0/cc1plus Thread 2.1 "cc1plus" received signal SIGABRT, Aborted. [Switching to process 15911] 0x00007ffff7bc3f71 in raise () from /lib64/libc.so.6 #0 0x00007ffff7bc3f71 in raise () from /lib64/libc.so.6 #1 0x00007ffff7bad537 in abort () from /lib64/libc.so.6 #2 0x00007ffff7c08207 in ?? () from /lib64/libc.so.6 #3 0x00007ffff7c99892 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007ffff7c99870 in __stack_chk_fail () from /lib64/libc.so.6 #5 0x000000000065a1f2 in cp_gimplify_expr(tree_node**, gimple**, gimple**) () #6 0x00000000009f4ffc in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #7 0x00000000009faeb1 in ?? () #8 0x00000000009f6304 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #9 0x00000000009f6196 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #10 0x00000000009f5d42 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #11 0x00000000009f6196 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #12 0x00000000009fd5b9 in ?? () #13 0x00000000009f638d in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #14 0x00000000009f6196 in gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) () #15 0x00000000009f9ed9 in gimplify_body(tree_node*, bool) () #16 0x00000000009fa316 in gimplify_function_tree(tree_node*) () #17 0x0000000000885f58 in cgraph_node::analyze() () #18 0x0000000000888878 in ?? () #19 0x00000000008894c3 in symbol_table::finalize_compilation_unit() () #20 0x0000000000c769b1 in ?? () #21 0x000000000060065a in toplev::main(int, char**) () #22 0x000000000060413c in main () (In reply to Sergei Trofimovich from comment #13) > (In reply to myloveyuxuan from comment #12) > > (In reply to Sergei Trofimovich from comment #5) > > > (In reply to Sergei Trofimovich from comment #4) > > > > I'll try to reproduce locally. > > > > > > > > > I was not able to reproduce locally in an -O3 -march=native chroot. That > > > probably means that gcc itself was mis-compiled for your target. Try to get > > > a symbolized gcc backtrace when if smashes it's sack. > > > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces should > > > help in that. > > > > Sure I can. > > > > Here is the summary of the more information added in the new comment. > > > > Comment 6 is the output of command `LANG=C gcc -Q --help=target` > > > > Comment 7 is the differences between the output of the command `LANG=C gcc > > -Q --help=target` and the command `LANG=C gcc -march=native -Q --help=target` > > > > Comment 8 is the output of command `LANG=C gcc -march=native -O3 -Q > > --help=optimizers` > > > > Comment 9 is the differences between the output of the command `LANG=C gcc > > -march=native -O3 -Q --help=optimizers` and the command `LANG=C gcc > > -march=native -O2 -Q --help=optimizers` > > > > Comment 10 is the symbolized gcc backtrace when smashes it's stack. > > Looks like it does not have line numbers attached. Usually extra debug info > can be obtained if compiled with -g (or -ggdb) added to CFLAGS/CXXFLAGS. > > > And the attachment in the Comment 11 is preprocessed file of xml_grammer.c > > Just to clarify: you see the crash if you run gcc on a preprocessed file as > well, right? > > Thank you! Sorry for confusing you. I have realized that I followed the wrong guide before. So I add a new attachment which content is what Comment 14 said. And I recompile gcc with `-ggdb` compiler flag and get the backtrace where the ICE happend again. There is something to notice, which that I retried the compile command which makes the ICE happen but the ICE does not always happen . Can you also check that sys-apps/memtest86+ or similar test does not report memory errors on your machine? (In reply to Sergei Trofimovich from comment #17) > Can you also check that sys-apps/memtest86+ or similar test does not report > memory errors on your machine? I just have run the sys-apps/memtest86+ for 3 hours but there is no any memory errors reported on my machine. Only sys-devel/gcc-10.1.0 compiling dev-libs/boost-1.73.0 will cause this issue. I have tried recompile all other packages on my machine without any issue. And I also tried to compile the sources from upstream without problem. Moreover, I recompiled gcc with **debug** use flag enabled. I can build dev-libs/boost-1.73.0 without any problem using recompiled gcc. (In reply to myloveyuxuan from comment #18) > I just have run the sys-apps/memtest86+ for 3 hours but there is no any > memory errors reported on my machine. Aha. Nice to have it checked. Let's assume it's a software bug then. (In reply to myloveyuxuan from comment #19) > Only sys-devel/gcc-10.1.0 compiling dev-libs/boost-1.73.0 will cause this > issue. > > I have tried recompile all other packages on my machine without any issue. > > And I also tried to compile the sources from upstream without problem. > > Moreover, I recompiled gcc with **debug** use flag enabled. I can build > dev-libs/boost-1.73.0 without any problem using recompiled gcc. That probably means data corruption is very sensitive to code layout generated for gcc-10 itself. Meanwhile I attempted to reproduce on zvnver2 machine with either '-march=native -O3' or '-O3 -pipe -march=znver1 -mmmx -mabm -madx -maes -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -msse4a -mssse3 -mavx -mavx -mbmi -mbmi2 -mclflushopt -mclzero -mcx16 -mf16c -mfma -mfsgsbase -mfxsr -mlzcnt -mmovbe -mmwaitx -mpclmul -mpopcnt -mprfchw -mrdrnd -mrdseed -msahf -msha -mtune=znver1 -mxsave -mxsavec -mxsaveopt -mxsaves -fdiagnostics-show-option -frecord-gcc-switches'. None fail for me. All work fine. 1. Does compiling preprocessed file fail for you if you run try to build it with expanded version of flags instead of -march=native? Would be nice to find out smaller set of flags to get a clue which arch-specific flags are involved. 2. Can you post detailed USE flags for gcc and it's dependencies? 'emerge --info sys-devel/gcc sys-libs/glibc' (In reply to Sergei Trofimovich from comment #20) > (In reply to myloveyuxuan from comment #18) > > I just have run the sys-apps/memtest86+ for 3 hours but there is no any > > memory errors reported on my machine. > > Aha. Nice to have it checked. Let's assume it's a software bug then. > > (In reply to myloveyuxuan from comment #19) > > Only sys-devel/gcc-10.1.0 compiling dev-libs/boost-1.73.0 will cause this > > issue. > > > > I have tried recompile all other packages on my machine without any issue. > > > > And I also tried to compile the sources from upstream without problem. > > > > Moreover, I recompiled gcc with **debug** use flag enabled. I can build > > dev-libs/boost-1.73.0 without any problem using recompiled gcc. > > That probably means data corruption is very sensitive to code layout > generated for gcc-10 itself. > > Meanwhile I attempted to reproduce on zvnver2 machine with either > '-march=native -O3' or '-O3 -pipe -march=znver1 -mmmx -mabm -madx -maes > -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2 -msse4a -mssse3 -mavx -mavx > -mbmi -mbmi2 -mclflushopt -mclzero -mcx16 -mf16c -mfma -mfsgsbase -mfxsr > -mlzcnt -mmovbe -mmwaitx -mpclmul -mpopcnt -mprfchw -mrdrnd -mrdseed -msahf > -msha -mtune=znver1 -mxsave -mxsavec -mxsaveopt -mxsaves > -fdiagnostics-show-option -frecord-gcc-switches'. None fail for me. All work > fine. > > 1. Does compiling preprocessed file fail for you if you run try to build it > with expanded version of flags instead of -march=native? > > Would be nice to find out smaller set of flags to get a clue which > arch-specific flags are involved. > > 2. Can you post detailed USE flags for gcc and it's dependencies? 'emerge > --info sys-devel/gcc sys-libs/glibc' 1. Yeah, I have tried it. But even if I delete all flags expanded from -march=native, gcc still smashing its stack at the same place. 2. The output of 'emerge --info sys-devel/gcc sys-libs/glibc' is in the next Comment. Something more about compilation, I tried to recompile the xml_grammar.cpp without -march=native and the ICE still happened. Created attachment 644360 [details]
The output of `emerge --info sys-devel/gcc sys-libs/glibc`
Created attachment 644362 [details]
The error messages when I try to compile xml_grammar.cpp for five times
Only the third time I can pass the compilation.
(In reply to myloveyuxuan from comment #22) > Created attachment 644360 [details] > The output of `emerge --info sys-devel/gcc sys-libs/glibc` Looks normal (except perhaps missing -ggdb for gcc, that explains why there are no debugging symbols). Can you somehow share a package of build and faulty gcc? It's about 70MB and can be generated by 'quickpkg gcc'. It should create a tarball. (In reply to Sergei Trofimovich from comment #24) > (In reply to myloveyuxuan from comment #22) > > Created attachment 644360 [details] > > The output of `emerge --info sys-devel/gcc sys-libs/glibc` > > Looks normal (except perhaps missing -ggdb for gcc, that explains why there > are no debugging symbols). > > Can you somehow share a package of build and faulty gcc? It's about 70MB and > can be generated by 'quickpkg gcc'. It should create a tarball. Already sent you the package via email. (In reply to myloveyuxuan from comment #25) > (In reply to Sergei Trofimovich from comment #24) > > (In reply to myloveyuxuan from comment #22) > > > Created attachment 644360 [details] > > > The output of `emerge --info sys-devel/gcc sys-libs/glibc` > > > > Looks normal (except perhaps missing -ggdb for gcc, that explains why there > > are no debugging symbols). > > > > Can you somehow share a package of build and faulty gcc? It's about 70MB and > > can be generated by 'quickpkg gcc'. It should create a tarball. > > > Already sent you the package via email. I'm afraid I did not receive anything. Can you post a link to the archive here if possible? (In reply to Sergei Trofimovich from comment #26) > (In reply to myloveyuxuan from comment #25) > > (In reply to Sergei Trofimovich from comment #24) > > > (In reply to myloveyuxuan from comment #22) > > > > Created attachment 644360 [details] > > > > The output of `emerge --info sys-devel/gcc sys-libs/glibc` > > > > > > Looks normal (except perhaps missing -ggdb for gcc, that explains why there > > > are no debugging symbols). > > > > > > Can you somehow share a package of build and faulty gcc? It's about 70MB and > > > can be generated by 'quickpkg gcc'. It should create a tarball. > > > > > > Already sent you the package via email. > > I'm afraid I did not receive anything. Can you post a link to the archive > here if possible? OK, here is the link https://drive.google.com/file/d/1UbaCrD_KqzOSuWst7acABDVB7SnDUSXP/view?usp=sharing (In reply to myloveyuxuan from comment #27) > OK, here is the link > > https://drive.google.com/file/d/1UbaCrD_KqzOSuWst7acABDVB7SnDUSXP/ > view?usp=sharing I also mirrored it at https://dev.gentoo.org/~slyfox/bugs/724314-gcc-znver1/gcc-10.1.0.tbz2 I unpacked this gcc on top of existing one and still can't reproduce crashes on boost. Neither on preprocessed file, nor on the boost ebuild. We can try a few other things heavyweight things: 1. Prepare complete chroot where the problem is reproducible. Then archive and share the whole chroot. I expect that to be about 500MB archive. 2. Run gcc's testsuite and compare failures with my znver system. Maybe we'll be able to spot faulty block. To do that you can build gcc with: 'FEATURES=test USE=test emerge -v1 gcc'. And the package up the whole gcc's build tree and share the archive. Created attachment 645596 [details]
Debug log
(In reply to Sergei Trofimovich from comment #28) > (In reply to myloveyuxuan from comment #27) > > OK, here is the link > > > > https://drive.google.com/file/d/1UbaCrD_KqzOSuWst7acABDVB7SnDUSXP/ > > view?usp=sharing > > I also mirrored it at > https://dev.gentoo.org/~slyfox/bugs/724314-gcc-znver1/gcc-10.1.0.tbz2 > > I unpacked this gcc on top of existing one and still can't reproduce crashes > on boost. Neither on preprocessed file, nor on the boost ebuild. > > We can try a few other things heavyweight things: > > 1. Prepare complete chroot where the problem is reproducible. Then archive > and share the whole chroot. I expect that to be about 500MB archive. > > 2. Run gcc's testsuite and compare failures with my znver system. Maybe > we'll be able to spot faulty block. To do that you can build gcc with: > 'FEATURES=test USE=test emerge -v1 gcc'. And the package up the whole gcc's > build tree and share the archive. 1. Sorry I can't reproduce the problem in chroot, too. All the problem disappeared when I get into chroot environment but still appears in the un-chroot environment. 2. Here is the gcc's build tree when I build gcc with 'FEATURES=test USE=test emerge -v1 gcc': https://drive.google.com/file/d/1d-ATqgN0H3ajJ9tm_yfIVrI4M9QIK1C2/view?usp=sharing and the gdb debug log after I compile gcc with 'FEATURES="${FEATURES} splitdebug compressdebug -nostrip"' and 'USE="debug"': https://bugs.gentoo.org/attachment.cgi?id=645596 (In reply to myloveyuxuan from comment #30) > (In reply to Sergei Trofimovich from comment #28) > > (In reply to myloveyuxuan from comment #27) > > > OK, here is the link > > > > > > https://drive.google.com/file/d/1UbaCrD_KqzOSuWst7acABDVB7SnDUSXP/ > > > view?usp=sharing > > > > I also mirrored it at > > https://dev.gentoo.org/~slyfox/bugs/724314-gcc-znver1/gcc-10.1.0.tbz2 > > > > I unpacked this gcc on top of existing one and still can't reproduce crashes > > on boost. Neither on preprocessed file, nor on the boost ebuild. > > > > We can try a few other things heavyweight things: > > > > 1. Prepare complete chroot where the problem is reproducible. Then archive > > and share the whole chroot. I expect that to be about 500MB archive. > > > > 2. Run gcc's testsuite and compare failures with my znver system. Maybe > > we'll be able to spot faulty block. To do that you can build gcc with: > > 'FEATURES=test USE=test emerge -v1 gcc'. And the package up the whole gcc's > > build tree and share the archive. > > 1. Sorry I can't reproduce the problem in chroot, too. > All the problem disappeared when I get into chroot environment but still > appears in the un-chroot environment. Hm, that might hint at external component at fault like glibc, gmp, mpc or mpfr. Try to rebuild full @world in the chroot with a new compiler and CFLAGS to see if gcc build starts failing again. > 2. Here is the gcc's build tree when I build gcc with 'FEATURES=test > USE=test emerge -v1 gcc': > > https://drive.google.com/file/d/1d-ATqgN0H3ajJ9tm_yfIVrI4M9QIK1C2/ > view?usp=sharing > > and the gdb debug log after I compile gcc with 'FEATURES="${FEATURES} > splitdebug compressdebug -nostrip"' and 'USE="debug"': > > https://bugs.gentoo.org/attachment.cgi?id=645596 Thank you! That looks good. I'll try to build binaries as close as possible to these. Can you also attach a /var/log/portage/sys-devel:gcc-10.1.0-r1:20200621-044743.log build log as well? It's a symlink in the archive. (In reply to Sergei Trofimovich from comment #31) > (In reply to myloveyuxuan from comment #30) > > (In reply to Sergei Trofimovich from comment #28) > > > (In reply to myloveyuxuan from comment #27) > > > > OK, here is the link > > > > > > > > https://drive.google.com/file/d/1UbaCrD_KqzOSuWst7acABDVB7SnDUSXP/ > > > > view?usp=sharing > > > > > > I also mirrored it at > > > https://dev.gentoo.org/~slyfox/bugs/724314-gcc-znver1/gcc-10.1.0.tbz2 > > > > > > I unpacked this gcc on top of existing one and still can't reproduce crashes > > > on boost. Neither on preprocessed file, nor on the boost ebuild. > > > > > > We can try a few other things heavyweight things: > > > > > > 1. Prepare complete chroot where the problem is reproducible. Then archive > > > and share the whole chroot. I expect that to be about 500MB archive. > > > > > > 2. Run gcc's testsuite and compare failures with my znver system. Maybe > > > we'll be able to spot faulty block. To do that you can build gcc with: > > > 'FEATURES=test USE=test emerge -v1 gcc'. And the package up the whole gcc's > > > build tree and share the archive. > > > > 1. Sorry I can't reproduce the problem in chroot, too. > > All the problem disappeared when I get into chroot environment but still > > appears in the un-chroot environment. > > Hm, that might hint at external component at fault like glibc, gmp, mpc or > mpfr. Try to rebuild full @world in the chroot with a new compiler and > CFLAGS to see if gcc build starts failing again. > > > 2. Here is the gcc's build tree when I build gcc with 'FEATURES=test > > USE=test emerge -v1 gcc': > > > > https://drive.google.com/file/d/1d-ATqgN0H3ajJ9tm_yfIVrI4M9QIK1C2/ > > view?usp=sharing > > > > and the gdb debug log after I compile gcc with 'FEATURES="${FEATURES} > > splitdebug compressdebug -nostrip"' and 'USE="debug"': > > > > https://bugs.gentoo.org/attachment.cgi?id=645596 > > Thank you! That looks good. I'll try to build binaries as close as possible > to these. Can you also attach a > /var/log/portage/sys-devel:gcc-10.1.0-r1:20200621-044743.log build log as > well? It's a symlink in the archive. I think the files in the gcc-build-logs.tar.bz2 is enough. And the content of the file "build.log" in "gcc-build-logs.tar.bz2" is same as the log "/var/log/portage/sys-devel:gcc-10.1.0-r1:20200621-044743.log". So I delete the log. (In reply to myloveyuxuan from comment #32) > > Thank you! That looks good. I'll try to build binaries as close as possible > > to these. Can you also attach a > > /var/log/portage/sys-devel:gcc-10.1.0-r1:20200621-044743.log build log as > > well? It's a symlink in the archive. > > I think the files in the gcc-build-logs.tar.bz2 is enough. And the content > of the file "build.log" in "gcc-build-logs.tar.bz2" is same as the log > "/var/log/portage/sys-devel:gcc-10.1.0-r1:20200621-044743.log". So I delete > the log. Ah, yes! That's perfect! *** Bug 729308 has been marked as a duplicate of this bug. *** Let's own the bug by toolchain@. I was not able to reproduce locally and still have not much clue. Jakub on #gcc suggested catching the place where stack corruption happens. It is straightforward if corruption is deterministic and less straightforward if it jumps around. We will need to find an address of stack canary that gets corrupted every time and set a watchpoint on it at the beginning of gimplify_expr() when it parses our expression. Given that it's quite generic function it will require some a bit of trial an error. I suggest doing the following: 1. Try to minimize preprocessed example to ease interactive gcc debugging with gdb. https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide#.5Bbonus.5D_minimize_self-contained_source_using_creduce . The catch there is to get the property. 2. Step through minimized example to see where stack canary is corrupted. The overall process is similar to https://bugs.gentoo.org/721570#c7 (example for arm64 architecture). But the details are different. I see that both reports have early Ryzen CPus: - System uname: Linux-5.7.2-gentoo-x86_64-AMD_Ryzen_5_1600_Six-Core_Processor-with-gentoo-2.7 (April 2017?) - System uname: Linux-5.6.15-gentoo-x86_64-x86_64-AMD_Ryzen_5_2500U_with_Radeon_Vega_Mobile_Gfx-with-glibc2.2.5 (November 2017?) Internets say that some early CPUs had bugs that cause crashes under the load: https://community.amd.com/thread/219812. If MAKEOPTS=-j1 makes the boost crash disappear that might be a point in favour of CPU bug. I don't know if there is a nice benchmark to detect if your CPU is really affected. I tried to compile with MAKEOPTS=-j1, but it crashes anyway Aha, that has a better chance of being software bug. Can you extract gdb backtrace to make sure it looks similar enough to https://bugs.gentoo.org/attachment.cgi?id=645596 ? I don't know why, but boost compiled without errors. Before that I compiled gcc with 'debug' use-flag and I added flag -ggdb to COMMON_FLAGS in the make.conf (In reply to user.light.man from comment #40) > I don't know why, but boost compiled without errors. Before that I compiled > gcc with 'debug' use-flag and I added flag -ggdb to COMMON_FLAGS in the > make.conf Can you clarify: boost was failing with gcc USE=debug/-ggdb or it succeeded when you changed to gcc USE=debug/-ggdb? the second, successfully compiled stack smashing happens again, but now in a program what I write oh no, it is not related with this problem, sorry (In reply to Sergei Trofimovich from comment #37) > I see that both reports have early Ryzen CPus: > > - System uname: > Linux-5.7.2-gentoo-x86_64-AMD_Ryzen_5_1600_Six-Core_Processor-with-gentoo-2. > 7 (April 2017?) > - System uname: > Linux-5.6.15-gentoo-x86_64-x86_64- > AMD_Ryzen_5_2500U_with_Radeon_Vega_Mobile_Gfx-with-glibc2.2.5 (November > 2017?) > > Internets say that some early CPUs had bugs that cause crashes under the > load: https://community.amd.com/thread/219812. > > If MAKEOPTS=-j1 makes the boost crash disappear that might be a point in > favour of CPU bug. I don't know if there is a nice benchmark to detect if > your CPU is really affected. I have tried reinstalling the system, building boost with MAKEOPTS="-j1" and without any other heavy work running at the same time, but the problem is still there. Perhaps try to minimise preprocessed example using https://wiki.gentoo.org/wiki/Gcc-ICE-reporting-guide#.5Bbonus.5D_minimize_self-contained_source_using_creduce . That should ease manual inspection where gcc crashes. I tried again. I built gcc without debug-flag. When I compile boost, a crash happens. Now I've built gcc with debug-flag. The compilation of boost succeeded. It occurs only in a non-debug build. -ggdb option doesn't matter In search for other clues, do you happen to have sys-devel/llvmgold installed on affected systems? That automatically installs a plugin into binutils that should not but might affect gcc. (In reply to Sergei Trofimovich from comment #48) > In search for other clues, do you happen to have sys-devel/llvmgold > installed on affected systems? That automatically installs a plugin into > binutils that should not but might affect gcc. I don't have sys-devel/llvmgold installed on affected systems. And I can't install creduce because some bugs that have to repair. eix sys-devel/llvmgold
[I] sys-devel/llvmgold
Available versions: 8 9 (~)10 **11*l
Installed versions: 10(04:28:19 PM 05/29/2020)
Homepage: https://llvm.org/
Description: LLVMgold plugin symlink for autoloading
(In reply to user.light.man from comment #50) > eix sys-devel/llvmgold > [I] sys-devel/llvmgold > Available versions: 8 9 (~)10 **11*l > Installed versions: 10(04:28:19 PM 05/29/2020) > Homepage: https://llvm.org/ > Description: LLVMgold plugin symlink for autoloading Can you try to deinstall it for a period of a short test: - rebuilding gcc - rebuiding glibc - rebuilding boost and check if boost still fails to build. I made these steps, it still fails I tried compile gcc with all kinds of combinations of USE flags. Finally I can make sure that the ICE disappears when I enable the **debug** USE flag. I am lack of knowledge about what EBUILD do with debug USE flag. So I would like believe that you can find the solution. Thank you. Hi, just to make sure. You had only the debug flag enabled or where the other flags as well? (In reply to myloveyuxuan from comment #53) > I tried compile gcc with all kinds of combinations of USE flags. Finally I > can make sure that the ICE disappears when I enable the **debug** USE flag. > I am lack of knowledge about what EBUILD do with debug USE flag. So I > would like believe that you can find the solution. > Thank you. Unfortunately, no. The USE=debug only changes gcc's code enough make real bug invisible (but still very present in gcc). We need to understand why the bug happens and extract smallest example that exhibits the bug. (In reply to Stig Nielsen from comment #54) > Hi, just to make sure. You had only the debug flag enabled or where the > other flags as well? Other flags may have no effects on it. I have tried enabling debug USE flag with profile default/linux/amd64/17.1/desktop/plasma, then compilation passed. But then I disable debug USE flag, it appeared again. So I tried enable only debug USE and other essential USE flags of gcc for compiling boost; the compilation passed. Then I tried disable debug USE, it appeared expectedly. (In reply to Sergei Trofimovich from comment #55) > (In reply to myloveyuxuan from comment #53) > > I tried compile gcc with all kinds of combinations of USE flags. Finally I > > can make sure that the ICE disappears when I enable the **debug** USE flag. > > I am lack of knowledge about what EBUILD do with debug USE flag. So I > > would like believe that you can find the solution. > > Thank you. > > Unfortunately, no. The USE=debug only changes gcc's code enough make real > bug invisible (but still very present in gcc). We need to understand why the > bug happens and extract smallest example that exhibits the bug. I will try my best to do that. But it probably makes debugging harder I added a https://wiki.gentoo.org/wiki/Project:Toolchain/724314-gcc-10-and-znver1#More_info to get some hints how to extract more info to debug it further. Specifically we need to track down where stack gets corrupted: https://wiki.gentoo.org/wiki/Stack-smashing-debugging-guide Seems that upstream has fixed it. (In reply to myloveyuxuan from comment #59) > Seems that upstream has fixed it. Do you have a link to the fix? (In reply to Sergei Trofimovich from comment #60) > (In reply to myloveyuxuan from comment #59) > > Seems that upstream has fixed it. > > Do you have a link to the fix? Here is the link: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=08f594eb399dab06 (In reply to myloveyuxuan from comment #61) > (In reply to Sergei Trofimovich from comment #60) > > (In reply to myloveyuxuan from comment #59) > > > Seems that upstream has fixed it. > > > > Do you have a link to the fix? > > Here is the link: > https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=08f594eb399dab06 How did you find it? That commit was already present in gcc-10.1.0 $ git tag --contains=08f594eb399dab06 | cat basepoints/gcc-11 misc/cutover-git releases/gcc-10.1.0 releases/gcc-10.2.0 I think it's not really and truly fixed. Maybe the commit cited (or other random changes) shuffled the corruption around in a way that didn't trigger SSP anymore but I think it's not really fixed. This patch is in =sys-devel/gcc-10.2.0-r2. I compiled it with my standard .*FLAGS of -march=native -O2 -ggdb on my 16-core zen+ ~amd64 box, (quite stable previously on gcc9), and all kinds of wacky hi-jinx ensued. Took a while to get to the bottom of it but this bug has to be the one. Although my gcc has the aformentioned patch in it, pretty much exactly the same behavior remains, compiling (what else but?) =dev-libs/boost-1.74.0-r1... Judging by other posts I see in wiki/bgo I'm not the only -march=znver? gentooer whose gcc woes didn't end a month ago. After effectively applying s/-march=[^[:space:]]*/-march=nocona/g to .*FLAGS to each */gcc ebuild (and nothing else, via package.env hacks), immediately, the boost ebuild stopped failing, and, as I progress through a @world rebuild, the "crazy" seems to be slowly draining out of my system. So, I suspect this is still an un-diagnosed bug, which is still being distributed to all (some?) gcc:10 -march=znver? consumers. Or else it regressed or has multiple causes, there's a CPU bug, etc.etc.etc. There are still no known fixes for this bug. We still need a reproducer to debug it effectively. (In reply to Sergei Trofimovich from comment #64) > There are still no known fixes for this bug. We still need a reproducer to > debug it effectively. Ug, afraid you would say something like that :) It was 100% reproducible here not too long ago, at least in the face of standard experiments like: ebuild clean boost-1.74.0-r1.ebuild x=0 export MAKEOPTS=-j1 while ! ebuild install boost-1.74.0-r1.ebuild; do (( x++ >= 10 )) && break done I might even have a backup I could call up, with a binary configuration with precisely that behavior? Of course, I couldn't possibly succeed, now that I've given the universe the opportunity to embarrass me for the sin of having publicly making forward looking statements. But, OK, you talked me into it :P Since it's the thought that counts, despite being doomed to jinx-induced failure, I'll futilely endeavor to make some time & do some experiments. Hooray...? This thing is kicking my butt. I think I need to downgrade this box to gcc9 for now as it doesn't seem like boost is the only thing affected.
Here is one interesting finding.
If I make /etc/portage/env/sys-devel/gcc-10.2.0-r2 like so:
pre_src_configure() {
strip-flags() {
ewarn "strip-flags: But I want them!"
}
}
and then replace my -march=native with purportedly equivalent horrors:
{C,CXX,FC,FF}FLAGS="-mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe \
-maes -msha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi \
-mno-sgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 \
-msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw \
-madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd \
-mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq \
-mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps \
-mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku -mno-rdpid -mno-gfni \
-mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq \
-mno-avx512bitalg -mno-avx512vpopcntdq -mno-movdiri -mno-movdir64b -mno-waitpkg \
-mno-cldemote -mno-ptwrite -mno-avx512bf16 -mno-enqcmd -mno-avx512vp2intersect \
--param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 \
<other flags, in my case, -ggdb -O2 -pipe>"
Everything is great.
Yet, if I simply prepend "-march=znver1" to the above flag-horror, then it breaks. This suggests, somewhere in the [gcc build -> ebuild install/merge -> boost ebuild -> boost-build -> gcc] process, somebody is doing something "extra" based on the "-march=znver[12]" case.
Perhaps, specifically, the gcc build does something for "-march=znver[12]" that is not captured by the above flag-horror. But if so, I never quite figured out where that "extra" stuff would come from.
Actually maybe I'll stay here for a bit, keep the strip-flags override, put those flag-horrors into my actual make.conf, and rebuild world just like that. (atm it's in a silly script only)
I'm curious to see if all the weird behaviors on my box go away (I have some other infrequent unexplained corruption/segfaults right now in chromium although that could easily be a different bug) or not.
So, in the course of chasing down sources of error, I found I /did/ have system instability. In particular I discovered that OCCT on windows was able to show memory corruption pretty quickly (prime95 on linux was rock solid, notably...). OCCT says it's an "AVX2" test. But who knows what that means, their software is proprietary. Anyhow, after fixing the OCCT failures, I managed to make other aspects of my system unstable! Ugh. So, it seems that either I've degraded my silicon, or the stability frontier on this system is non-monotonic in some weird way. Or any of several seemingly innocuous things I changed were, in fact, nocuous :) Or, you know, any of the usual stupid meatspace things, like cracked pcb, failing smt component, thermal dissipation snafu, etc. We'll see, the jury is still out. Because it was very repeatable, I doubt my ICE was caused by my hardware issues. But I've not yet ruled it out and I'd like to before continuing. I've not been able to falsify the hypothesis that I've achieved system stability for a good while, here, so, hopefully, I'm on the right track... sigh, you know the drill, H0=it's stable, but p0(P(Ha)) is the unknown function of the unknown probability that you're not in fact stable, but have failed to observe a failure yet.... so not much you can do there except try your best to cause a problem for a while and then eventually declare "OK it's stable now".... So I've been running into this exact boost compilation failure on a fresh system install... I've been going down the rabbit hole until I found this issue... I'm running a Ryzen 7 1700 machine - aka znver1 CPU, and I'd naively set my CFLAGS="-O2 -pipe -march=znver1". The stage3 installed fine and let me work my way up to a bootable and mildly usable desktop. The issue began when I upgraded GCC to 10.2.0 from 9 previously... I have not yet recompiled gcc with the -debug flag, which seems to be the way around this, short of downgrading to gcc 9. I'm looking for a way in which I can help, given my limited knowledge of C/C++ toolchains. I'm happy giving slyfox SSH rights to my machine as indicated at the bottom of (https://wiki.gentoo.org/wiki/Project:Toolchain/724314-gcc-10-and-znver1#More_info). To be clear, I re-installed Gentoo starting last night, and have not done anything utterly exotic, so the chroot generation should be relatively straightforward with a ryzen 1x00 CPU host machine. This is still an unresolved issue for me. (In reply to goeland86 from comment #68) > So I've been running into this exact boost compilation failure on a fresh > system install... > > I've been going down the rabbit hole until I found this issue... > > I'm running a Ryzen 7 1700 machine - aka znver1 CPU, and I'd naively set my > CFLAGS="-O2 -pipe -march=znver1". > > The stage3 installed fine and let me work my way up to a bootable and mildly > usable desktop. The issue began when I upgraded GCC to 10.2.0 from 9 > previously... Let's reopen the issue if you can somewhat reliably reproduce the failure. > I have not yet recompiled gcc with the -debug flag, which seems to be the > way around this, short of downgrading to gcc 9. I'm looking for a way in > which I can help, given my limited knowledge of C/C++ toolchains. I'm happy > giving slyfox SSH rights to my machine as indicated at the bottom of > (https://wiki.gentoo.org/wiki/Project:Toolchain/724314-gcc-10-and- > znver1#More_info). > > To be clear, I re-installed Gentoo starting last night, and have not done > anything utterly exotic, so the chroot generation should be relatively > straightforward with a ryzen 1x00 CPU host machine. > > This is still an unresolved issue for me. My ssh public key is https://dev.gentoo.org/~slyfox/keys/id_rsa4096.pub. If you can send me details on slyfox@gentoo.org I'll try to debug the crash on target host. I'll probably need ability to install various tools to chroot including rebuilding gcc in various debug modes. @slyfox: email with connection details sent. I also listed the steps that brought me to this bug, and that caused the failure to repeat, despite a number of different USE and CFLAG configurations. I'll paste it here for visibility: 1. Install base Gentoo using stage3 tarball from a livecd, using the systemd Gnome profile 2. Reboot onto disk-based Gentoo 3. Install packages, including gcc-10. One of the packages required gcc-10 to compile 4. gcc-config -s <gcc 10 index> 5. after a few more installs and USE updates for multimedia (you'll have direct access to the /etc/portage dir), run emerge -uNDav --with-bdeps=y @world and then boost compilation failed. 6. Googled my way down the rabbit hole to https://bugs.gentoo.org/724314 7. Tried a number of different CFLAGS / USE variations, recompiling gcc with them from what I found on forums or various wiki/doc pages. The stack corruption repeated always at the same spot consistently like the one detailed by myloveyuxuan in comment #4 8. manually emerged gcc 10 with USE="debug" 9. Re-ran #5 and it passed successfully. I forgot the above #7 I'm putting here in the email... oops. (In reply to goeland86 from comment #70) > @slyfox: email with connection details sent. Thank you! I'll dump a bit of state here on what I got to and what is yet to do: 1. I reproduced the failure on znver1 machine. Some possibly relevant environment details: - kernel: 5.9.8-gentoo - sys-devel/gcc-10.2.0-r3::gentoo was built with the following: - USE="(cxx) fortran graphite (multilib) nls nptl openmp pch (pie) sanitize ssp vtv (-ada) -d -debug -doc (-fixed-point) -go (-hardened) -jit (-libssp) -lto -objc -objc++ -objc-gc -pgo -systemtap -test -vanilla -zstd" ABI_X86="(64)" - CFLAGS="-pipe -march=znver1 -O2" - CXXFLAGS="-pipe -march=znver1 -O2" 2. I debugged the crash in gdb and I think it's not a stack corruption, but a more complicated bug in how context switches are handled on this system, specifically: - The bug is not very deterministic: sometimes gcc crashes, sometimes does not on seemingly identical environment even if gcc is ran under gdb. - When gcc crashes crash location is mostly stable. Usually it's 2-3 locations where stack corruption happens. Always in 'cp_gimplify_expr()' function. Probably because it's a rare function with stack canary. - Stack canary value at program start and at crash time are the same (== no stack corruption), but delta between values is non-zero. That means canary is being read from wrong location. Now I'm trying to understand which process' canary is being used (if any instead of some garbage value) to better understand how failure looks like. My (equally bizarre) hypotheses are: - some process context switch problem possibly related to modern instruction sets being used (kernel bug) - a CPU cache-related bug (missing cache flush?) We can patch glibc to store useful payload into stack canary somewhere at: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/generic/dl-osinfo.h;h=c9cc7f14996154549d81b248edfb49b6e4fff383;hb=HEAD#l22 Hey, guys. I've been meaning to get around to testing with gcc graphite use-flag disabled.
ATM,though, I'm not really able to break my system (even temporarily) because ${reasons[*]}.
So ... if someone feels like humoring me, maybe give it a try?
TBC there is no really compelling reason to think it will work -- in fact, I don't even remember exactly how I got this idea (graphite bug activity in bugzilla?)
But even a stopped clock is right once or twice a day (depending on nationality and/or military/civilian status) Maybe it's a lucky guess -- probably not but one way to be sure :S
A few more clues around stack canary handling. We can explore exact contents of expected and actual canaries in gdb (need to run a few times until it crashes): $ gdb --quiet -ex start -ex 'break __stack_chk_fail' -ex continue --args /usr/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/cc1plus -quiet -v -D_GNU_SOURCE a.cpp.cpp -quiet -dumpbase a.cpp.cpp -mtune=generic -march=x86-64 -auxbase-strip a.o -O2 -Wno-inline -std=c++14 -version -fvisibility-inlines-hidden -fvisibility=hidden -o a.o Breakpoint 2, 0x00007ffff785fd40 in __stack_chk_fail () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff785fd40 in __stack_chk_fail () from /lib64/libc.so.6 #1 0x0000000000662e02 in cp_gimplify_expr(tree_node**, gimple**, gimple**) () ... (gdb) disassemble cp_gimplify_expr ... 0x0000000000662175 <+37>: mov %fs:0x28,%rax 0x000000000066217e <+46>: mov %rax,0x78(%rsp) 0x0000000000662183 <+51>: xor %eax,%eax ... 0x000000000066223c <+236>: nopl 0x0(%rax) 0x0000000000662240 <+240>: mov 0x78(%rsp),%rax 0x0000000000662245 <+245>: sub %fs:0x28,%rax 0x000000000066224e <+254>: jne 0x662dfd <cp_gimplify_expr+3245> ... 0x0000000000662dfd <+3245>: call 0x5c6050 <__stack_chk_fail@plt> Here we see the following: - original stack canary is stored at %fs:0x28 (mov %fs:0x28,%rax) - stack canary copy is stored at '$rsp + 0x78' (mov %rax,0x78(%rsp)) - supposed delta between current value and actual value is still in '$rax' when '__stack_chk_fail' is called (mov 0x78(%rsp),%rax / sub %fs:0x28,%rax) We can check what actual value of canary was "read" from stack at crash time: (gdb) print *(void**)($rsp + 0x78) + $rax $3 = (void *) 0x7fffffff6ff0 While we expected a different value: (gdb) print *(void**)($rsp + 0x78) $4 = (void *) 0xe3db10cb06ca8500 Or the same via %fs:0x28: (gdb) x/1a *(void **)$rsp + 0x28 0x7ffff7750ae8: 0xe3db10cb06ca8500 Here is the actual stack and delta values for completeness: (gdb) print $rsp $6 = (void *) 0x7fffffff7540 (gdb) print (void*)$rax $8 = (void *) 0x1c256f34f934eaf0 My guess is that 'sub %fs:0x28,%rax' was reading data from very unexpected location. which might hint at stale value of fsbase segment. We do see that unexpected value at least on stack, but at unrelated location: Breakpoint 2, 0x00007ffff785fd40 in __stack_chk_fail () from /lib64/libc.so.6 (gdb) fr 1 #1 0x0000000000662e02 in cp_gimplify_expr(tree_node**, gimple**, gimple**) () (gdb) print *(void**)($rsp + 0x78) + $rax $1 = (void *) 0x7fffffff6ff0 (gdb) find /g $rsp-1000000, $rsp+1000, 0x7fffffff6ff0 0x7fffffff6db8 0x7fffffff6e48 2 patterns found. *** Bug 730406 has been marked as a duplicate of this bug. *** Hello everybody,
I'm another user on znver1 (AMD Ryzen 7 1700, family 23 model 1 stepping 1) experiencing the gcc crash compiling boost, in the course of rebuilding it for dev-libs/icu-68.1. This was with -j1 and occurs very consistently, so it does not seem to be related to a processor glitch under load. I have sys-devel/gcc-10.2.0-r3 and everything else ~amd64 up to date.
Actually I'm on gcc-10 for a while now and never experienced problems - after all this is a full workstation system with postgresql, libreoffice and many more big systems, so one should think this is stress-tested sufficiently. As said, boost is recompiled for icu, so the same boost compiled fine with gcc-10 against icu-67 before. I just don't know whether it was gcc-10.2.0-r3 since I recompiled gcc yesterday, without effect, so the original install date of that specific version is lost.
Do you want me to do specific tests?
I build both 32 and 64 bit versions, the error occurs on the first, -m32 pass:
"x86_64-pc-linux-gnu-g++" "-m32" -fvisibility-inlines-hidden -march=znver1 -O2 -pipe -std=c++14 -fPIC -m32 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/serialization/build/gcc-10.2/gentoorelease/pch-off/threading-multi/visibility-hidden/xml_grammar.o" "libs/serialization/src/xml_grammar.cpp"
*** stack smashing detected ***: terminated
In file included from libs/serialization/src/xml_grammar.cpp:64:
libs/serialization/src/basic_xml_grammar.ipp: In constructor ‘boost::archive::basic_xml_grammar<CharType>::basic_xml_grammar() [with CharType = char]’:
libs/serialization/src/basic_xml_grammar.ipp:364:9: internal compiler error: Aborted
360 | str_p(BOOST_ARCHIVE_XML_CLASS_NAME())
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
361 | >> Eq
| ~~~~~
362 | >> L'"'
| ~~~~~~~
363 | >> ClassName
| ~~~~~~~~~~~~
364 | >> L'"'
| ^~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
...failed updating 1 target...
Same issue here when compiling on AMD ThreadRipper 1950X with MAKEOPTS=j1, but the error is below.
"x86_64-pc-linux-gnu-g++" -fvisibility-inlines-hidden -march=native -O2 -pipe -std=c++14 -fPIC -m64 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL_DYN_LINK=1 -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I"." -c -o "bin.v2/libs/wave/build/gcc-10.2/gentoorelease/pch-off/threading-multi/visibility-hidden/instantiate_cpp_exprgrammar.o" "libs/wave/src/instantiate_cpp_exprgrammar.cpp"
*** stack smashing detected ***: terminated
In file included from libs/wave/src/instantiate_cpp_exprgrammar.cpp:24:
./boost/wave/grammars/cpp_expression_grammar.hpp: In constructor ‘boost::wave::grammars::expression_grammar::definition<ScannerT>::definition(const boost::wave::grammars::expression_grammar&) [with ScannerT = boost::spirit::classic::scanner<std::_List_const_iterator<boost::wave::cpplexer::lex_token<> >, boost::spirit::classic::scanner_policies<boost::spirit::classic::skip_parser_iteration_policy<boost::spirit::classic::alternative<boost::spirit::classic::alternative<boost::spirit::classic::chlit<boost::wave::token_id>, boost::spirit::classic::chlit<boost::wave::token_id> >, boost::spirit::classic::chlit<boost::wave::token_id> >, boost::spirit::classic::iteration_policy>, boost::spirit::classic::match_policy, boost::spirit::classic::action_policy> >]’:
./boost/wave/grammars/cpp_expression_grammar.hpp:554:17: internal compiler error: Aborted
541 | = primary_exp[unary_exp.val = arg1]
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
542 | | ch_p(T_PLUS) >> unary_exp
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
543 | [
| ~
544 | unary_exp.val = arg1
| ~~~~~~~~~~~~~~~~~~~~
545 | ]
| ~
546 | | ch_p(T_MINUS) >> unary_exp
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
547 | [
| ~
548 | unary_exp.val = -arg1
| ~~~~~~~~~~~~~~~~~~~~~
549 | ]
| ~
550 | | pattern_p(T_COMPL, MainTokenMask) >> unary_exp
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
551 | [
| ~
552 | unary_exp.val = ~arg1
| ~~~~~~~~~~~~~~~~~~~~~
553 | ]
| ~
554 | | pattern_p(T_NOT, MainTokenMask) >> unary_exp
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
555 | [
| ~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://bugs.gentoo.org/> for instructions.
...failed updating 1 target...
* ERROR: dev-libs/boost-1.74.0-r1::gentoo failed (compile phase):
Yeah, the errors are roughly the same. I'm trying to build a smaller test on a target system that exhibits the failure. So far the suspects are kernel bug and CPU bug. Small bit of status update: I'm reducing example further on target machine to ease failure mechanics. I'm down to 1313 bytes of c++ :) But not yet very close to exact core that confuses CPU. If it's of any consolation I found a few small deficiencies in g++: - https://gcc.gnu.org/PR98286 - https://gcc.gnu.org/PR98306 They are (probably) unrelated to observed failure. But they sidetracked me twice into something that looks like c++ for g++ but is really not. Debugging further. what's make me curious is that I have built successfully boost-1.74 with gcc-10.2 before on the system, but now this time I changed the python version to 3.8 and the rebuilt of boost failed. I assume there may be change for gcc patchset. But hard to tell which one cause the issue. While changes in python version might make a difference, yesterday I had two failures in a row and then a successful emerge of boost-1.74 with gcc-10. 2. I also had more than two failures of genkernel to compile boost 1.73 for the initramfs and then a successful run. All those runs were with no other updates or changes between them. Something here is not 100% deterministic and reproducible, which is likely part of why it has been so hard to solve. Same error with gcc-10.2-r4 with kernel 5.10.1 May be of help, may not. A few days ago, with an up to date machine, I had built Boost 1.74.0-r1 successfully. An emerge today brought in 1.74.0-r2. This suffered from "stack smashing" as listed here. Using package.env, I've set up Boost to build using clang v11.0.0, instead and the build was successfully. I'm currently running: Gentoo sources kernel, 5.10.2 gcc 10.2.0-r4 p5 clang, clang++ V11.0.0 Python 3.9.1 AMD Ryzen 7 2700 Eight-Core Processor MAKEOPTS="-j5" (In reply to Bluey The Dog from comment #83) > May be of help, may not. A few days ago, with an up to date machine, I had > built Boost 1.74.0-r1 successfully. An emerge today brought in 1.74.0-r2. > This suffered from "stack smashing" as listed here. Using package.env, I've > set up Boost to build using clang v11.0.0, instead and the build was > successfully. I'm currently running: > > Gentoo sources kernel, 5.10.2 > gcc 10.2.0-r4 p5 > clang, clang++ V11.0.0 > Python 3.9.1 > AMD Ryzen 7 2700 Eight-Core Processor > MAKEOPTS="-j5" Thanks,this method works for me now and also learned a new method to control how the system build. *** Bug 761685 has been marked as a duplicate of this bug. *** (In reply to Greg Turner from comment #72) > Hey, guys. I've been meaning to get around to testing with gcc graphite > use-flag disabled. > > ATM,though, I'm not really able to break my system (even temporarily) > because ${reasons[*]}. > > So ... if someone feels like humoring me, maybe give it a try? Folks, I finally got around to giving my hunch a try. And ... drumroll... disabling the graphite use flag in sys-devel/gcc:10 works around this bug on my zen+ system. So obviously that doesn't fix the bug. But it does fix my box, yay! Also it provides an avenue of investigation toward finding a real fix (specifically, graphite-related changes between 9.x.x and 10.1.x seem to merit some scrutiny). Created attachment 682072 [details]
telegram build log
Created attachment 682075 [details]
telegram source where stack smashing occurs
Source file telegram build stack smashes on
Created attachment 682078 [details]
telegram-emerge-info
emerge info for telegram build
I was pointed to this bug from IRC when I ran into a stack smashing error building telegram-desktop. Build log and source file attached. I HAVE successfully built telegram with gcc historically, with znver1 CPU/march=native on this hardware. I first noticed this occur while building a new Gentoo root after a root FS failure. Boost version is dev-libs/boost-1.74.0-r1:0/1.74.0::gentoo Created attachment 682081 [details] Emerge order of packages (In reply to Greg Turner from comment #86) > (In reply to Greg Turner from comment #72) > > Hey, guys. I've been meaning to get around to testing with gcc graphite > > use-flag disabled. > > > > ATM,though, I'm not really able to break my system (even temporarily) > > because ${reasons[*]}. > > > > So ... if someone feels like humoring me, maybe give it a try? > > Folks, I finally got around to giving my hunch a try. And ... drumroll... > disabling the graphite use flag in sys-devel/gcc:10 works around this bug on > my zen+ system. > > So obviously that doesn't fix the bug. But it does fix my box, yay! Also > it provides an avenue of investigation toward finding a real fix > (specifically, graphite-related changes between 9.x.x and 10.1.x seem to > merit some scrutiny). I do NOT have graphite enabled and I still experience this issue. Further to my previous comments, out of curiosity I attempted to re-emerge boost (the version that I have already successfully built during setup) and the SAME version fails to build, with the stack smashing problem. I've attached the emerge order of my packages. Another possible cause that I remembered is different to my last system where boost/telegram built fine is I have ABI 32 and 64 set up globally, whereas before it was done selectively for things required for Steam. (In reply to ninpo from comment #91) > (In reply to Greg Turner from comment #86) > > drumroll... > > I do NOT have graphite enabled and I still experience this issue. :( Out of curiosity is anyone experiencing this issue and NOT using any kind of multilib? The only other change I recall making after my last successful build of boost with gcc was switching from 64 to 64 and 32bit ABI globally. Thought I'd ask before rebuilding my whole system. Created attachment 682741 [details]
build.log for boost-1.75 for Intel CPU with gentoo-lto
Looks like I am experiencing the same bug, although I use Intel CPU. Attachment in the comment 94 is the build.log for boost on my machine. I did a successful system update, but the bug is still here. Also I have got graphite and GentooLTO enabled, so they might be the case. Also I will recompile gcc with debug flag and post the results. (In reply to meks from comment #95) > Looks like I am experiencing the same bug, although I use Intel CPU. > > Attachment in the comment 94 is the build.log for boost on my machine. I did > a successful system update, but the bug is still here. Also I have got > graphite and GentooLTO enabled, so they might be the case. > > Also I will recompile gcc with debug flag and post the results. Going by your build log, what is it that makes you think it's the same problem? I don't see any mention of stack smashing.. (In reply to ninpo from comment #96) > (In reply to meks from comment #95) > > Looks like I am experiencing the same bug, although I use Intel CPU. > > > > Attachment in the comment 94 is the build.log for boost on my machine. I did > > a successful system update, but the bug is still here. Also I have got > > graphite and GentooLTO enabled, so they might be the case. > > > > Also I will recompile gcc with debug flag and post the results. > > Going by your build log, what is it that makes you think it's the same > problem? I don't see any mention of stack smashing.. Sorry, you're right, this is an unrelated issue. I didn't notice that. By the way, recompiling gcc with debug flag did not help. (In reply to meks from comment #97) > (In reply to ninpo from comment #96) > > (In reply to meks from comment #95) > > > Looks like I am experiencing the same bug, although I use Intel CPU. > > > > > > Attachment in the comment 94 is the build.log for boost on my machine. I did > > > a successful system update, but the bug is still here. Also I have got > > > graphite and GentooLTO enabled, so they might be the case. > > > > > > Also I will recompile gcc with debug flag and post the results. > > > > Going by your build log, what is it that makes you think it's the same > > problem? I don't see any mention of stack smashing.. > > Sorry, you're right, this is an unrelated issue. I didn't notice that. > > By the way, recompiling gcc with debug flag did not help. Please file a separate bug. I am experiencing the same ICE when trying to compile boost-1.75.0 with gcc-10.2.0 on and for a Threadripper 1950X system with -02 -march=native. Compiling the same boost code using gcc-9.3.0 worked fine. Hey guys, just a bit of speculation/thoughts. If we just let toolchain.eclass do it's thing, it will eviscerate our CFLAGS, but I have at various times tried something like:
src_configure() {
THE_OLD_CFLAGS=${CFLAGS}
THE_OLD_CXXFLAGS=${CXXFLAGS}
.
.
toolchain_src_configure
CFLAGS=${THE_OLD_CFLAGS}
CXXFLAGS=${THE_OLD_CXXFLAGS}
.
.
}
in an overlay, and convinced myself that
o -mtune=znver1 is enough to trigger the bug (pretty sure that's right)
o replacing -march/-mtune with the corresponding flags as indicated by various gcc debugging commands does not suffice to trigger the bug (much less confident of this as those commands seem a bit ... squishy? Less than clear, I suppose, about what is being provided/guaranteed).
Sadly, the more I think about the specific tests I did, the less confidence I have in my results. I think I wasn't nearly careful enough to confidently treat either of the above "findings" as anything more than mere conjectures. So... can anyone disconfirm either of these?
One thing I am confident about is that if I put -march=generic in there, I get a working gcc. Specifically, doing so for only the gcc:10 ebuild suffices to get things up and running here, without suffering from this bug on my Zen+ box, even when the rest of the system is built with -march=znver1, btw.
For what I could get from debugging on host that exhibits a problem the crash is very obscure and probably not a direct fault of gcc but more likely a CPU (or kernel) bug. gcc only happens to generate code that trips over mysterious condition where data read from stack does not match reality. We still need to extract exact reproducer. (In reply to Sergei Trofimovich from comment #101) > For what I could get from debugging on host that exhibits a problem the > crash is very obscure and probably not a direct fault of gcc but more likely > a CPU (or kernel) bug. > > gcc only happens to generate code that trips over mysterious condition where > data read from stack does not match reality. We still need to extract exact > reproducer. Could be, but to me it smells like a head-slapper thinko. I know determinism is low for some people experiencing this, but on my box, it's 100% repeatable. To wit, the boost ebuild fails 100% of the time, always on the same make target, and (I think but have not strictly confirmed) with a functionally identical backtrace, regardless of parallelism, for a given /etc + gcc combo. That, or, it doesn't fail at all, and succeeds 100% of the time. (ok, not strictly true over the full life of this bug... but I think the exceptions were unrelated. Pretty confident I have full repeatability right now). It would take some doing and gobble a ton of watt-hours, but, assuming local repeatability maintains throughout revision history, I could automate a log2 git-commit regression hunt... I've been telling myself that's too expensive, but it's winter now... maybe since I'd save a bit on natural gas (and no fix seems to be around the corner), it's worth it now. Bisecting compiler would probably not provide extra signal. Seemingly unrelated code change affects the bug trigger. Bisecting kernel might (if there is a kernel version or configuration that happens to work). *** Bug 776595 has been marked as a duplicate of this bug. *** *** Bug 779439 has been marked as a duplicate of this bug. *** *** Bug 779886 has been marked as a duplicate of this bug. *** Recompiling gcc actually fixed it for me. I have another report (me) of "recompile GCC without the arch specific build flag set" resolving this issue. I was hitting this when building a kernel. Thanks to the IRC channel dudes (particularly iamben who ALWAYS helps) for pointing me this way. I have tested this on my machine (AMD 3200U znver1) with gcc 10.0.2.0 and 10.0.3.0 and everything go fine Just to be clear: dev-libs/boost-1.75.0 Shocked to see this is such a long running issue. I did a fresh install the other day without issue, installed my DE and went on. I had to reinstall after an unrelated issue, though, and now boost refuses to compile. The only difference I could think of was that I had used the dist-kernel 5.11.12 instead of 5.11.11 but even downgrading the kernel didn't help. I also tried using different versions of gcc but nothing worked. I also tried changing my -march between native and znver1 (Ryzen 1700) (In reply to Isaac Crawford from comment #111) > Shocked to see this is such a long running issue. I did a fresh install the > other day without issue, installed my DE and went on. I had to reinstall > after an unrelated issue, though, and now boost refuses to compile. The only > difference I could think of was that I had used the dist-kernel 5.11.12 > instead of 5.11.11 but even downgrading the kernel didn't help. I also tried > using different versions of gcc but nothing worked. I also tried changing my > -march between native and znver1 (Ryzen 1700) Can you recompile GCC without -march set AT ALL and then try the kernel again? This is how I got things moving again... (In reply to Neil Stone from comment #112) > Can you recompile GCC without -march set AT ALL and then try the kernel > again? This is how I got things moving again... Ill try that out and let you know how it goes. Im currently installing the new 5.11.13 kernel to see if that will make a difference. If 13 doesnt work, Ill unset -march and run through the different kernel versions. Once you got it working again, were you able to set -march back again? How do you think that will affect future @world updates and such? I cant imagine its healthy to leave that unset. (In reply to Isaac Crawford from comment #113) > (In reply to Neil Stone from comment #112) > > Can you recompile GCC without -march set AT ALL and then try the kernel > > again? This is how I got things moving again... > > Once you got it working again, were you able to set -march back again? How > do you think that will affect future @world updates and such? I cant imagine > its healthy to leave that unset. in /etc/portage/bashrc you could put something like: if [[ -n ${EBUILD_PHASE} && ${CATEGORY}/${PN} == sys-devel/gcc ]]; then ewarn "gmt: hack: strip (-ish) -march cflags" local flagvar= subflag= nnewstring= oldstring= for flagvar in CFLAGS CXXFLAGS FCFLAGS FFLAGS; do if [[ ${!flagvar} == *-march* ]]; then local oldmarch= local newmarch= local newstring= local oldstring="${!flagvar}" for aflag in ${oldstring}; do case ${aflag} in -march=*) local poldmarch=${aflag#-march=} case ${poldmarch} in x86_64|i686|generic) newstring+="${newstring:+ }${aflag}" ;; *) oldmarch=${poldmarch} newmarch=$( case ${ABI} in amd64) echo x86_64 ;; x86) echo i686 ;; x32) echo x86_64 ;; *) echo generic ;; esac ) newstring+="${newstring:+ }-march=${newmarch}" ;; esac ;; -mtune=*) # just drop it! :; ;; *) newstring+="${newstring:+ }${aflag}" ;; esac done eval "${flagvar}=${newstring@Q}" if [[ ${oldstring} == ${newstring} ]]; then ewarn "gmt: didn't hack up ${flagvar} as it already seemed fine:" ewarn "gmt: ${flagvar}=${oldstring@Q}" else ewarn "gmt: hacked up ${flagvar}:" ewarn " old: ${oldstring@Q}" ewarn " new: ${newstring@Q}" fi fi done fi After that, you should in theory get non-optimized gcc and you can leave make.conf alone. However I haven't tested the first line of code above (I use something much more stupidly complicated to get this code to run :P)... so sorry if I screwed up that line. The rest of it works. Unless I'm forgetting more than I think I'm forgetting which is pretty plausible :) Well the good news is that unsetting -march definitely seems to work! Sorry Greg, I read your comment after already letting gcc compile and going to sleep. I wish I was more familiar with bash scripting, though, that seems like it would be a more elegant solution. I'm currently emerging the rest of my desktop environment packages and I set -march back to native. Ill see if updates to boost are affected afterwards. Hi, just my two cents: my CPU is AMD Ryzen Threadripper 1950X 16-Core Processor I have disabled HT. No multilib (ABI_X86="64") CFLAGS is _expanded_ -march=native gcc without grapihte Everytihing works as expected except for bulding boost 1.75.0 [ebuild R ] sys-devel/gcc-10.2.0-r5:10::gentoo USE="(cxx) fortran jit (multilib) nls nptl openmp pch (pie) sanitize ssp (-ada) -d -debug -doc (-fixed-point) -go -graphite (-hardened) (-libssp) -lto -objc -objc++ -objc-gc -pgo -systemtap -test -vanilla -vtv -zstd" 0 KiB Build fails even with unset -march and -mtune (with rebuilt gcc and libtool and MAKEOPTS="-j1") (In reply to samurai.no.dojo from comment #116) Appending CFLAGS for completness CFLAGS="--param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=512 -O2 -fomit-frame-pointer -mabm -madx -maes -mavx -mavx2 -mbmi -mbmi2 -mclflushopt -mclzero -mcx16 -mf16c -mfma -mfsgsbase -mfxsr -mlzcnt -mmmx -mmovbe -mmwaitx -mpclmul -mpopcnt -mprfchw -mrdrnd -mrdseed -msahf -msha -msse -msse2 -msse3 -msse4.1 -msse4.2 -msse4a -mssse3 -mxsave -mxsavec -mxsaveopt -mxsaves -pipe" Is anyone aware of any progress on this bug? I know a number of people have setup workarounds here and there, but something official and ideally in tree would be a much nicer way to address this. Before putting a workaround we need to understand why failure happens. If it's a CPU bug then the only fix is to swap it. Yeah, same thing here. This seems to have started recently for me. The build log and emerge info output at https://gist.github.com/ILMostro/68806b4dc83ccfce176eaf8ed15b8411 . I had recently switched to "CONFIG_MZEN" kernel config option. I had hoped that changing the kernel config back to "CONFIG_MNATIVE_AMD" would resolve this, but the problem persists. Curiously, this does seem to coincide with another system-wide python version upgrade; i.e. python3_8 --> python3_9. Although, that may not be the cause of these failures. FWIW, I booted into kernels 5.10.16-gentoo and 5.9.15-gentoo to try to rebuild. The problem persists. I also have this problem where building boost 1.75.0 and 1.76.0 with gcc 10.2.0-r5 fails with stack smashing detected. I am not using graphite or debug at the moment, and have march=znver1 with my Ryzen 1800X. *** Bug 789087 has been marked as a duplicate of this bug. *** (In reply to Adrian from comment #122) > I also have this problem where building boost 1.75.0 and 1.76.0 with gcc > 10.2.0-r5 fails with stack smashing detected. I am not using graphite or > debug at the moment, and have march=znver1 with my Ryzen 1800X. I just emerge gcc with debug use flags and custom-flags (CFLAGS="-Og -g -ggdb -march=znver1 -pipe") enabled, and I also had "splitdebug compressdebug -nostrip installsources" features enabled. But all the ICE disappared. It's wierd. (In reply to myloveyuxuan from comment #124) > (In reply to Adrian from comment #122) > > I also have this problem where building boost 1.75.0 and 1.76.0 with gcc > > 10.2.0-r5 fails with stack smashing detected. I am not using graphite or > > debug at the moment, and have march=znver1 with my Ryzen 1800X. > > I just emerge gcc with debug use flags and custom-flags (CFLAGS="-Og -g > -ggdb -march=znver1 -pipe") enabled, and I also had "splitdebug > compressdebug -nostrip installsources" features enabled. But all the ICE > disappared. > > It's wierd. I can't upload my build logs due to 500 error of bugzilla. Thanks I was going to try rebuilding gcc with the debug flag next, but was a bit concerned reading comment 55 that it will just leave the stack overflow present but unreported in my system. (In reply to Adrian from comment #126) > Thanks I was going to try rebuilding gcc with the debug flag next, but was a > bit concerned reading comment 55 that it will just leave the stack overflow > present but unreported in my system. Sorry, I just forgot the comment 55 but there is still no ICE while emerging boost-1.76.0 after I disabling the debug flag and rebuild gcc, even if I have tried many times. After many times of trying, I have found that only gcc compiled with -O2 cflags can lead to the issue. But I don't know how to find the clue of why this happened. Because I only get the backtrace with many optimized out variables. Created attachment 706833 [details]
new debug logs when I found out where the ICE happened.
I have no knowledge of the macros in gcc source codes. This is all I can do. And the log shows where I stop debugging.
For me also, after compiling GCC with debug I can successfully emerge boost 1.75.0. I am now trying to disable the GCC debug flag and see if still works as you suggested. (In reply to myloveyuxuan from comment #128) > After many times of trying, I have found that only gcc compiled with -O2 > cflags can lead to the issue. But I don't know how to find the clue of why > this happened. > Because I only get the backtrace with many optimized out variables. Can you clarify that, please? Does that mean that using the "-O3" or "-Ofast" flags works, while "-O2" only has the problem? When I don't have the debug use flag enabled, I can confirm I am able to build boost if I use O3 for gcc 10.2, but that the boost build fails due to the stack smashing when I compile gcc using O2. Getting gcc 10.2 to build with O3 takes some effort: /etc/portage/env/gcc-o3.conf: CFLAGS="-march=znver1 -O3 -pipe" /etc/portage/package.env/gcc: sys-devel/gcc gcc-o3.conf /etc/portage/package.use/gcc sys-devel/gcc custom-cflags /usr/portage/eclass/toolchain.eclass: Change tc_version_is_at_least 11 && IUSE+=" custom-cflags to tc_version_is_at_least 10 && IUSE+=" custom-cflags to prevent stripping the changed use flags It might be worth making this change to the toolchain.eclass in the tree to make this workaround easier for others to apply. (In reply to Amel Hodzic from comment #131) > (In reply to myloveyuxuan from comment #128) > > After many times of trying, I have found that only gcc compiled with -O2 > > cflags can lead to the issue. But I don't know how to find the clue of why > > this happened. > > Because I only get the backtrace with many optimized out variables. > > Can you clarify that, please? Does that mean that using the "-O3" or > "-Ofast" flags works, while "-O2" only has the problem? For me, I couldn't find any ICE when I was compiling boost with gcc compiled with "-O3" and "-Ofast" cflags. (In reply to myloveyuxuan from comment #129) > Created attachment 706833 [details] > new debug logs when I found out where the ICE happened. > > I have no knowledge of the macros in gcc source codes. This is all I can do. > And the log shows where I stop debugging. I am just tring to redo this with gcc compiled with "-O3" and "-Ofast" cflags. And I find it that ICE can always be triggered by this breakpoint. Created attachment 707136 [details]
new debug logs when I found a pointer with invalid value.
(In reply to myloveyuxuan from comment #135) > Created attachment 707136 [details] > new debug logs when I found a pointer with invalid value. Probably because gcc didn't make the pointer null after it disposed the node. (In reply to myloveyuxuan from comment #133) > (In reply to Amel Hodzic from comment #131) > > (In reply to myloveyuxuan from comment #128) > > > After many times of trying, I have found that only gcc compiled with -O2 > > > cflags can lead to the issue. But I don't know how to find the clue of why > > > this happened. > > > Because I only get the backtrace with many optimized out variables. > > > > Can you clarify that, please? Does that mean that using the "-O3" or > > "-Ofast" flags works, while "-O2" only has the problem? > > For me, I couldn't find any ICE when I was compiling boost with gcc compiled > with "-O3" and "-Ofast" cflags. That's odd. I have set CFLAGS="-march=native -Ofast -pipe" in "/etc/portage/make.conf" and building dev-libs/boost still fails as before. Trying to recompile @world again (including gcc) with CFLAGS="-march=native -O3 -pipe" now, in hopes of resolving this as you mentioned. I doubt that will work, but I am intrigued why you report that building boost succeeds for you with that configuration. I never tried Ofast, but found that O3 worked for me. Do you know that your gcc is actually compiling with the new CFLAGS? It took a few changes which I outline in comment 132 for me to ensure that the toolchain does not sanitise them back to O2. -O2 -march=native and -O3 both with and without -march=native didn't work for me. -Ofast -pipe (no -march=native) did. yeah, that's more related to the native or znver1 optimizations, I think. I did check to make sure that the compilations were being done with the updated CFLAGS even when they failed. So, whether it was O2, O3, or Ofast, it's always failed for me, including a recent attempt to reinstall libreoffice. As a workaround, I am masking gcc version 10. Hopefully this will get resolved. Based on Sergei's observations in comment #70: "Stack canary value at program start and at crash time are the same (== no stack corruption), but delta between values is non-zero. That means canary is being read from wrong location." That sounds like it might be related to ASLR. Although, I have tried to find it on my ASRock X399 Taichi UEFI settings, I was not able to locate it to disable that feature to test this hypothesis. I don't think I have UEFI settings for ASLR on my motherboard. Is it worth trying disabling it in the kernel through /proc/sys/kernel/randomize_va_space? Hey, I had the same problem with building boost-1.75.0 with gcc 10.2.0-r5. Also AMD System (Ryzen 2700) with -march=native active and -O2. But I noticed that gcc 10.2.0 standard is compiled without USE Flag "vtv" which was enabled on gcc 9.3.0 f.e. . So I just tried it with a gcc 10 compiled with "vtv" and -march=native and -O2 still active. And it DID work out. No problem at all. Before 100% failure while building boost. Maybe this information helps. Greetings Hi, confirming adding (back) vtv gcc USE flags makes boost compile (again) with both gcc-10.3.0 and gcc-11.1.0 after over 6 months of reproducible failures. Thanks Please post the following: 1. `emerge --info` 2. `arch=znver1; for t in param target; do cmd="gcc -Q -O2 -march=$arch --help=$t"; diff -U0 <(LANG=C $cmd) <(LANG=C $cmd -march=native); ` Huh. I tried adding vtv to the compilation of GCC 10.2.0-r5. GCC itself compiles fine, but when compiling boost 1.75.0 with it I still get the same ICE as before. Created attachment 712935 [details] emerge --info (In reply to Sergei Trofimovich from comment #144) > Please post the following: > 1. `emerge --info` > 2. `arch=znver1; for t in param target; do cmd="gcc -Q -O2 -march=$arch > --help=$t"; diff -U0 <(LANG=C $cmd) <(LANG=C $cmd -march=native); ` 1. attached 2. no output (i've added a "done") On a second thought there were 2 changes on the system: gcc 11 vs 10 and, as mentioned, vtv in package.use for sys-devel/gcc (In reply to acab from comment #143) > Hi, confirming adding (back) vtv gcc USE flags makes boost compile (again) > with both gcc-10.3.0 and gcc-11.1.0 after over 6 months of reproducible > failures. Out of curiosity I've just rebuilt sys-devel/gcc-11.1.0 without vtv and the re-emerge of dev-libs/boost-1.76.0-r1 fails in the usual way. TL;DR: for me vtv in gcc consistently solves (or works around) the issue Interesting; building Boost 1.76.0 with gcc 10.2.0-r5 (with vtv) worked fine, while it failed to build Boost version 1.75.0. (In reply to Jan C Peters from comment #148) > Interesting; building Boost 1.76.0 with gcc 10.2.0-r5 (with vtv) worked > fine, while it failed to build Boost version 1.75.0. Most people report considerable nondeterminism in this bug. I had a deterministic manifestation of the bug and a nondeterministic manifestation at various moments. I suggest testing with a shell script that tries experiments multiple times and then announces a success count and a fail count, to prevent your brain from jumping to conclusions :) You're not alone -- I, for one, have had to retract numerous "findings" above for similar reasons. Comment on attachment 712935 [details] emerge --info Same bug on dev-libs/boost-1.75.0 and dev-libs/boost-1.76.0-r1. The program compiles successfully on an Intel and an older AMD processer but crasses on my Ryzen 3 1200. If required I can supply my 'info' and 'pqv' data. "x86_64-pc-linux-gnu-g++" "-m32" -fvisibility-inlines-hidden -march=znver1 -O2 -pipe -std=c++14 -fPIC -m32 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -ftemplate- depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/serialization/build/gcc-10.3/gentoorelease /pch-off/threading-multi/visibility-hidden/xml_grammar.o" "libs/serialization/src/xml_grammar.cpp" *** stack smashing detected ***: terminated In file included from ./boost/compressed_pair.hpp:18, from ./boost/spirit/home/classic/core/composite/composite.hpp:12, from ./boost/spirit/home/classic/core/composite/sequence.hpp:16, from ./boost/spirit/home/classic/core/composite/operators.hpp:13, from ./boost/spirit/include/classic_operators.hpp:11, from libs/serialization/src/basic_xml_grammar.ipp:28, from libs/serialization/src/xml_grammar.cpp:64: ./boost/detail/compressed_pair.hpp: In constructor ‘boost::details::compressed_pair_imp<T1, T2, 0>::compressed_pair_imp(boost::details::compressed_pair_imp<T1, T2, 0>::first_param_type, boos t::details::compressed_pair_imp<T1, T2, 0>::second_param_type) [with T1 = boost::spirit::classic::sequence<boost::spirit::classic::sequence<boost::spirit::classic::sequence<boost::spirit::cl assic::sequence<boost::spirit::classic::optional<boost::spirit::classic::rule<boost::spirit::classic::scanner<__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >, boost::s pirit::classic::scanner_policies<> >, boost::spirit::classic::nil_t, boost::spirit::classic::nil_t> >, boost::spirit::classic::chlit<char> >, boost::spirit::classic::action<boost::spirit::cl assic::rule<boost::spirit::classic::scanner<__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >, boost::spirit::classic::scanner_policies<> >, boost::spirit::classic::nil_ t, boost::spirit::classic::nil_t>, boost::archive::xml::assign_impl<std::__cxx11::basic_string<char> > > >, boost::spirit::classic::rule<boost::spirit::classic::scanner<__gnu_cxx::__normal_i terator<char*, std::__cxx11::basic_string<char> >, boost::spirit::classic::scanner_policies<> >, boost::spirit::classic::nil_t, boost::spirit::classic::nil_t> >, boost::spirit::classic::opti onal<boost::spirit::classic::rule<boost::spirit::classic::scanner<__gnu_cxx::__normal_iterator<char*, std::__cxx11::basic_string<char> >, boost::spirit::classic::scanner_policies<> >, boost::spirit::classic::nil_t, boost::spirit::classic::nil_t> > >; T2 = boost::spirit::classic::chlit<char>]’: ./boost/detail/compressed_pair.hpp:120:32: internal compiler error: Aborted 120 | : first_(x), second_(y) {} | ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.gentoo.org/> for instructions. gcc.compile.c++ bin.v2/libs/serialization/build/gcc-10.3/gentoorelease/pch-off/threading-multi/visibility-hidden/basic_text_wiprimitive.o "x86_64-pc-linux-gnu-g++" "-m32" -fvisibility-inlines-hidden -march=znver1 -O2 -pipe -std=c++14 -fPIC -m32 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/serialization/build/gcc-10.3/gentoorelease/pch-off/threading-multi/visibility-hidden/basic_text_wiprimitive.o" "libs/serialization/src/basic_text_wiprimitive.cpp" gcc.compile.c++ bin.v2/libs/serialization/build/gcc-10.3/gentoorelease/pch-off/threading-multi/visibility-hidden/xml_oarchive.o "x86_64-pc-linux-gnu-g++" "-m32" -fvisibility-inlines-hidden -march=znver1 -O2 -pipe -std=c++14 -fPIC -m32 -pthread -finline-functions -Wno-inline -Wall -fvisibility=hidden -ftemplate-depth-255 -fvisibility=hidden -fvisibility-inlines-hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/serialization/build/gcc-10.3/gentoorelease/pch-off/threading-multi/visibility-hidden/xml_oarchive.o" "libs/serialization/src/xml_oarchive.cpp" ...skipped <pbin.v2/libs/serialization/build/gcc-10.3/gentoorelease/pch-off/threading-multi/visibility-hidden>libboost_serialization.so.1.76.0 for lack of <pbin.v2/libs/serialization/build/gcc-10.3/gentoorelease/pch-off/threading-multi/visibility-hidden>xml_grammar.o... ...skipped <p/var/tmp/portage/dev-libs/boost-1.76.0-r1/work/boost_1_76_0-abi_x86_32.x86/stage/lib>libboost_serialization.so.1.76.0 for lack of <pbin.v2/libs/serialization/build/gcc-10.3/gentoorelease/pch-off/threading-multi/visibility-hidden>libboost_serialization.so.1.76.0... ...failed updating 1 target... * ERROR: dev-libs/boost-1.76.0-r1::gentoo failed (compile phase): * (no error message) * * Call stack: * ebuild.sh, line 125: Called src_compile * environment, line 3325: Called multilib-minimal_src_compile * environment, line 2040: Called multilib_foreach_abi 'multilib-minimal_abi_src_compile' * environment, line 2310: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile' * environment, line 1987: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_compile' * environment, line 1985: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_compile' * environment, line 485: Called multilib-minimal_abi_src_compile * environment, line 2034: Called multilib_src_compile * environment, line 2522: Called die * The specific snippet of code: * ejam --prefix="${EPREFIX}"/usr "${OPTIONS[@]}" || die; * I must mention that I tried to install using -march=native rather than -march=znver1 and it crashed in the same manner.I note above that there was a failure on an Intel processor. I found no problem with the machine I have which uses a core2 Intel processor set with -march=haswell (In reply to Greg Turner from comment #149) > (In reply to Jan C Peters from comment #148) > > Interesting; building Boost 1.76.0 with gcc 10.2.0-r5 (with vtv) worked > > fine, while it failed to build Boost version 1.75.0. > > Most people report considerable nondeterminism in this bug. I had a > deterministic manifestation of the bug and a nondeterministic manifestation > at various moments. > > I suggest testing with a shell script that tries experiments multiple times > and then announces a success count and a fail count, to prevent your brain > from jumping to conclusions :) You're not alone -- I, for one, have had to > retract numerous "findings" above for similar reasons. Indeed the bug seems to happen nondeterministically; I just tried to compile Boost 1.76.0 with GCC 10.3.0, and the first time it exited with the ICE, the second time it worked fine. I did not change anything, just rerun emerge -1 boost. Really strange. After recompiling gcc with vtv pgo and lto it compiled for me (I was hitting a similar internal error. It may or may not be due to the flags, but it was failing pretty reliably up until then. I read above comment on addition of flags to gcc. Emerged gcc-10.3.0 with addition of vtv,pgo,lto flags. boost-1.76.0-r1 then compiled. I am using latest Ryzen kernel 5.12.9-zen1. This seems to be the answer. Successfully built dev-libs/boost-1.76.0-r1 after recompiling gcc-10.3 with lto, pgo, vtv use flags. Previous attempts included: Changing to march=native and recompiling gcc Adding vtv use flag and recompiling gcc Changing to march=native and adding vtv use flag and recompiling gcc Kernel: gentoo-source-5.10.27 I was also able to rebuild boost too (finally) using gcc 11.1.0 I first added the vtv flag, no luck. I then added the pgo flag and everything built fine. I did not add the lto flag (that would have been my next step) Following Jason Collisons example I re-executed the necessary emerges without the lto flag, and can confirm I found it was not required. For follow up, I rebuilt gcc without the vtv flag, but leaving the pgo flag. I then rebuilt boost again without issue. For my system, it appears that the pgo flag was the secret sauce, not the vtv flag. I am using a threadripper 1950x with CFLAGS="-march=native -O2 -pipe" Hope that helps someone more with more know-how than I figure this thing out. (In reply to Jason C from comment #158) > I then rebuilt boost again without issue. For my system, it appears that the > pgo flag was the secret sauce, not the vtv flag. The opposite is true for me: vtv *reliably* enables the boost build, pgo makes no difference. Ryzen Threadripper 1900X -march=native Linux 5.11.2 But, to complicate the matter, I've fired a phase3 image in docker on the same host (with the idea of giving access to some of the devs) but gcc-11.1 happily builds boost-1.76 there WITHOUT vtv or pgo. Spooky... I was unable to compile boost with gcc 11.1(In reply to acab from comment #159) > (In reply to Jason C from comment #158) > > I then rebuilt boost again without issue. For my system, it appears that the > > pgo flag was the secret sauce, not the vtv flag. > > The opposite is true for me: vtv *reliably* enables the boost build, pgo > makes no difference. > Ryzen Threadripper 1900X > -march=native > Linux 5.11.2 > > But, to complicate the matter, I've fired a phase3 image in docker on the > same host (with the idea of giving access to some of the devs) but gcc-11.1 > happily builds boost-1.76 there WITHOUT vtv or pgo. Spooky... So strange that this is so variable. Could there be a step that I am missing? Does emerge -av1 trigger a full rebuild, or would recently compiled parts be available and used instead? (In reply to Jason C from comment #160) > So strange that this is so variable. Could there be a step that I am > missing? Does emerge -av1 trigger a full rebuild, or would recently compiled > parts be available and used instead? gcc flag flips tells nothing about the triggering condition itself. There are a lot more moving parts here than just gcc flags: - kernel configuration (hardening, concurrent threads) - libc code, user's environment variables (cache access patterns) This bug is very likely not a bug in gcc. gcc only happens to be a first victim. #c71 has some hints. Whatever causes gcc's code pattern to change makes the bug to be masked away. It does not mean the underlying bug disappeared. It just corrupts your data in a less visible way. USE=pgo happens to be a very disruptive change that modifies cp_gimplify_expr() function enough that a condition does not trigger. Throwing in containers into the mix might further disrupt the environment. Though filesystem namespaces (chroot) did not make the bug away when I had a chance to explore it on affected system. We still need to extract exact code sequence from gcc ideally that triggers stack corruption in a standalone binary (possibly preserving memory layout and memory access sequence). Someone with access to the affected system would need to spend some (== A Lot) time on it. Unfortunately it's not a mechanical operation. My point is: whatever workaround you got working (removing =march=native, enabling USE=pgo, etc.) does not get us much closer to understanding (and fixing) the bug. (In reply to Sergei Trofimovich from comment #161) > (In reply to Jason C from comment #160) > > So strange that this is so variable. Could there be a step that I am > > missing? Does emerge -av1 trigger a full rebuild, or would recently compiled > > parts be available and used instead? > > gcc flag flips tells nothing about the triggering condition itself. There > are a lot more moving parts here than just gcc flags: > > - kernel configuration (hardening, concurrent threads) > - libc code, user's environment variables (cache access patterns) > > This bug is very likely not a bug in gcc. gcc only happens to be a first > victim. #c71 has some hints. > > Whatever causes gcc's code pattern to change makes the bug to be masked > away. It does not mean the underlying bug disappeared. It just corrupts your > data in a less visible way. > > USE=pgo happens to be a very disruptive change that modifies > cp_gimplify_expr() function enough that a condition does not trigger. > > Throwing in containers into the mix might further disrupt the environment. > Though filesystem namespaces (chroot) did not make the bug away when I had a > chance to explore it on affected system. > > We still need to extract exact code sequence from gcc ideally that triggers > stack corruption in a standalone binary (possibly preserving memory layout > and memory access sequence). Someone with access to the affected system > would need to spend some (== A Lot) time on it. Unfortunately it's not a > mechanical operation. > > My point is: whatever workaround you got working (removing =march=native, > enabling USE=pgo, etc.) does not get us much closer to understanding (and > fixing) the bug. Maybe I need to find a way for you to access my computer. I'd already granted access to my Ryzen 1700 machine. The process was slow going and I've needed it running for other purposes the last few months. But I'm happy to restore access to it to @slyfox if it will help him. The sandbox & files are still there. Jon For what it is worth: I have the same CFLAGS and CPU as Jason, and I also tried GCC (10.3.0) with USE=pgo now; indeed that reliably "fixes" the ICE for me. I tried recompiling boost 1.76.0 five times just to be sure there is no nondeterminism involved, and it built successfully every time. For what it's worth I'd like to point out that the bug did not exist on my Ryzen 3 200, or at least show up, prior to version 1.75.0. This could have some relevance, I assume, since changes in the code might have caused it to occur. Could someone enlighten me? pgo 'profile guided optimisation'. Isn't that what we want? Taking the literal meaning of the phrase it would seem to be good thing for gcc to optimise itself to match he particular profile of the computer being used.It dosn't surprise me that different processors might require a moderated compiler. And it does work on Ryzen processors! Not being an experienced computer programmer, I should be keen to hear from one who can correct my literal understanding of this technical phrase which is new to me, but in the abscence of any other explanation, I must take it at it's literal meaning. (In reply to Graham Young from comment #166) > Could someone enlighten me? pgo 'profile guided optimisation'. Isn't that > what we want? Taking the literal meaning of the phrase it would seem to be > good thing for gcc to optimise itself to match he particular profile of the > computer being used.It dosn't surprise me that different processors might > require a moderated compiler. And it does work on Ryzen processors! > > Not being an experienced computer programmer, I should be keen to hear from > one who can correct my literal understanding of this technical phrase which > is new to me, but in the abscence of any other explanation, I must take it > at it's literal meaning. USE=pgo is very tangential to this bug. https://en.wikipedia.org/wiki/Profile-guided_optimization has some details. Tl;DR if it is that PGO requires at least two build stages: 1. to instrument the binary to calculate execution statistics on a specific input (in case of gcc input of gcc is gcc's own source) 2. use execution statistics from [1.] (instead of compiler heuristics) to guide optimizations like inlining and code execution likelyhood (hot/cold path optimization). There is nothing processor-specific about PGO and it has a few caveats. The final set of optimizations usually differs slightly (or a lot) from build to build even for the seemingly same environment. It's a great way to get unique binary (and unique bugs that nobody could reproduce). If PGO reliably fixed the problem it could serve as a starting point. i.e., if PGO frobbed 16 frobs and reliably fixed the problem, we could find the set of superfluous non-problem-influencing frobs in uh... interesting math problem actually ... anyhow ... eventually. But does it reliably fix the problem? I know several posters have stated "this is it!" but how many times did they repeat their tests? I'm guessing, one, maybe two -- not nearly enough. For example assume the problem still crops up 10% of the time with pgo on. And assume also everybody is trying twice. Then the false negative rate of detection would be 81% (say 100 affected testers run twice. in their first run 10 affected testers get a positive result leaving 90 testers. In those 90 testers' second run we lose another 9 who get positive results. The remaining 81 testers all got type ii errors -- false negative results). It's pretty easy to imagine (in such a situation) that the pool of test samples failed to produce a single positive example of failure, and yet everyone still suffers from this bug. This is especially so because many Zen 1 users are starting from a point of 100% reproducibility leading to a situation where the idea that they are now entering some kind of bayes law situation is deeply counterintuitive and leads to lots of confirmation bias and data-collection-fatigue -- again if this sounds like I'm belittling you bear in mind I have been a victim of this as well. BTW ftr I don't really see this error anymore with gcc-11. I did have a single failed kernel compile (sig11) several weeks ago but it was after hardware maintenance and this box definitely gets weird for a bit after hw maintenance events. It didn't seem like this bug. My gcc 10.x builds are still affected. (In reply to Greg Turner from comment #168) > BTW ftr I don't really see this error anymore with gcc-11. To be clear, taking my own medicine, I may be affected. I just haven't seen any failures in a good long while. My thanks to Sergei Trofimovich for his reply. The problem now seems to lie in mistrust of a solution, which works for me, rather than the program to be compiled. In the abscence of any alternative solution and since I can't have the computer sitting idle, I must adopt the principle "if it works don't fix it". I'm getting this same build problem:
*** stack smashing detected ***: terminated
In file included from libs/serialization/src/xml_wgrammar.cpp:146:
libs/serialization/src/basic_xml_grammar.ipp: In constructor ‘boost::archive::basic_xml_grammar<CharType>::basic_xml_grammar() [with CharType = wchar_t]’:
libs/serialization/src/basic_xml_grammar.ipp:426:9: internal compiler error: Aborted
422 | str_p(L"signature")
| ~~~~~~~~~~~~~~~~~~~
423 | >> Eq
| ~~~~~
424 | >> L'"'
| ~~~~~~~
425 | >> Name [xml::assign_object(rv.class_name)]
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
426 | >> L'"'
| ^~~~~~~
I'm also on an older Ryzen chip:
vendor_id : AuthenticAMD
cpu family : 23
model : 8
model name : AMD Ryzen 7 2700X Eight-Core Processor
stepping : 2
microcode : 0x8008206
emerge --info '=dev-libs/boost-1.76.0-r1::gentoo'
!!! Repository 'matrix' has sync-uri attribute, but is missing sync-type attribute
Portage 3.0.18 (python 3.8.9-final-0, default/linux/amd64/17.1, gcc-10.3.0, glibc-2.33, 5.4.24-gentoo x86_64)
=================================================================
System Settings
=================================================================
System uname: Linux-5.4.24-gentoo-x86_64-AMD_Ryzen_7_2700X_Eight-Core_Processor-with-glibc2.2.5
KiB Mem: 65781580 total, 3657080 free
KiB Swap: 64804856 total, 44023588 free
Timestamp of repository gentoo: Fri, 11 Jun 2021 06:00:01 +0000
Head commit of repository gentoo: 613c3dd5dc4c96c93eaa06af6a65f2e8571bc987
sh bash 5.1_p8
ld GNU ld (Gentoo 2.35.2 p1) 2.35.2
app-shells/bash: 5.1_p8::gentoo
dev-java/java-config: 2.3.1::gentoo
dev-lang/perl: 5.32.1::gentoo
dev-lang/python: 2.7.18_p9::gentoo, 3.6.13_p3::gentoo, 3.7.10_p3::gentoo, 3.8.9_p2::gentoo, 3.9.4_p1::gentoo
dev-lang/rust: 1.51.0-r2::gentoo
dev-util/cmake: 3.18.5::gentoo
dev-util/pkgconfig: 0.29.2::gentoo
sys-apps/baselayout: 2.7::gentoo
sys-apps/openrc: 0.42.1-r1::gentoo
sys-apps/sandbox: 2.24::gentoo
sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake: 1.11.6-r3::gentoo, 1.16.3-r1::gentoo
sys-devel/binutils: 2.35.2::gentoo
sys-devel/gcc: 10.3.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.10::gentoo (virtual/os-headers)
sys-libs/glibc: 2.33::gentoo
Repositories:
gentoo
location: /usr/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-metamanifest: yes
sync-rsync-extra-opts:
sync-rsync-verify-jobs: 1
sync-rsync-verify-max-age: 24
penguindreams-org
location: /usr/local/portage
masters: gentoo
priority: 0
4nykey
location: /var/lib/layman/4nykey
masters: gentoo
priority: 50
hamper-overlay
location: /var/lib/layman/hamper-overlay
masters: gentoo
priority: 50
java
location: /var/lib/layman/java
masters: gentoo
priority: 50
matrix
location: /var/lib/layman/matrix
sync-uri: https://anongit.gentoo.org/git/repo/proj/matrix.git
masters: gentoo
priority: 50
sabayon
location: /var/lib/layman/sabayon
masters: gentoo
priority: 50
src_prepare-overlay
location: /var/lib/layman/src_prepare-overlay
masters: gentoo
priority: 50
steam-overlay
location: /var/lib/layman/steam-overlay
masters: gentoo
priority: 50
tlp
location: /var/lib/layman/tlp
masters: gentoo
priority: 50
tmacedo
location: /var/lib/layman/tmacedo
masters: gentoo
priority: 50
vampire
location: /var/lib/layman/vampire
masters: gentoo
priority: 50
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE Sublime PUEL dotnet-eula bh-luxi all-rights-reserved MSttfEULA freedist intel-ucode free-noncomm linux-fw-redistributable no-source-code CC-BY-ND-3.0 dropbox Broadcom EULA linux-firmware unRAR Skype-TOS codehaus-groovy as-is Microsoft ValveSteamLicense CC-Sampling-Plus IDEA Activision ChexQuest3 DOOM-COLLECTORS-EDITION CC-Sampling-Plus-1.0 codehaus-classworlds JSON FAH-special-permission FAH-EULA-2014 AMD-GPU-PRO-EULA FraunhoferFDK ms-teams-pre Snes9x NPSL"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe -march=native"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/easy-rsa /usr/share/gnupg/qualified.txt /usr/share/maven-bin-3.8/conf"
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 /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -march=native"
DISTDIR="/usr/portage/distfiles"
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 fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms splitdebug strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="en"
MAKEOPTS="-j6"
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="/var/tmp"
USE="X a52 aac aalib acl acpi aim alsa amd64 aspell audiofile avahi berkdb bluetooth browserplugin bzip2 cairo cdinstall cdparanoia cdr cleartype cli corefonts crypt cups dbus dmenu dri dts dvd dvdr dvdread egl elogind emacs emul-linux-x86 exif fam ffmpeg firefox fish-completion flac fortran ftp gdbm gif glamor gles gpm gstreamer gtk2 gtkhtml gudev hal hwdb iconv ipv6 java jpeg ldap libcaca libglvnd libtirpc log4j mad matroska mmx mono mp3 mp4 mpd mpeg msn multilib mysql ncurses nls nptl nptlonly offensive ogg oggvorbis opengl openmp pam pcre pdf png policykit pulseaudio quicktime readline real rtc samba sdl seamonkey seccomp spell split-usr sse sse2 ssl svg tcpd theora tiff tracker truetype type1 unicode usb v4l vaapi vcd vorbis wayland webp win32codecs wmf xattr xinerama xmms xscreensaver xvid yahoo zlib" ABI_X86="32 64" ADA_TARGET="gnat_2018" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir uusertrack 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="synaptics evdev" KERNEL="linux" L10N="en en-US en_US" 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" NGINX_MODULES_HTTP="access auth_basic autoindex browser charset empty_gif fastcgi geo gzip limit_conn limit_req map memcached proxy referer rewrite scgi split_clients ssi upstream_ip_hash userid uwsgi headers_more" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3 php7-4" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_8" PYTHON_TARGETS="python2_7 python3_6 python3_7 python3_8" RUBY_TARGETS="ruby25 ruby26" USERLAND="GNU" VIDEO_CARDS="amdgpu radeonsi" 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, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RUSTFLAGS
Created attachment 715356 [details]
boost-1.76.0-r1.build.log
(In reply to Greg Turner from comment #169) > (In reply to Greg Turner from comment #168) > > BTW ftr I don't really see this error anymore with gcc-11. > > To be clear, taking my own medicine, I may be affected. I just haven't seen > any failures in a good long while. aaand it's back. =gcc-11.1.0-r1. Most likely I was only temporarily free of it (either statistically or repeatably) because I had missed the new "custom-cflags" gcc useflag, and was therefore getting a non-gcc-optimized-gcc :( Built that one with pgo too, on a lark. So, no, confirming here that +pgo is not a repeatable silver bullet. Created attachment 718944 [details, diff]
revert-empty-class-copy-avoidance.patch
I got fed up with this and git bisected it. The attached patch, applied to =sys-devel/gcc-10.3.0-r1 and =sys-devel/gcc-11.1.0-r1 via /etc/portage/patches enabled me to build =dev-libs/1.76.0-r1 50 times per gcc without failure (whereas during the entire bisection process (14 splits! ugh), affected gcc's always failed within six attempts. Not sure how many confidence-sigmas that gives us, but at least one I'm sure.
So this is very probably an actual work-around. Now: how can we turn this into a useful bug that we can submit to gcc? I believe they have my copyright assignment on file from way back.
Also: w00t!
(In reply to Greg Turner from comment #174) > enabled me to build =dev-libs/1.76.0-r1 50 times =dev-libs/boost-1.76.0-r1* Filing bugs does not require any copyright assignments. Just file one on https://gcc.gnu.org/bugzilla/ and explain the details. (In reply to Sergei Trofimovich from comment #176) > Filing bugs does not require any copyright assignments. Just file one on > https://gcc.gnu.org/bugzilla/ and explain the details. ACK, I'll probably try to repro outside of Gentoo at this point, as I find bug reports with the word "Gentoo" in them are understandably treated with a bit of circumspection out there in non-Gentoo places... I also fear people in a position to understand the bug may not have a huge intersection with people in a position to reproduce it and want to make reproduction as easy and clear-cut as possible. That's mostly why I haven't bothered opening a bug up to now (the other issue is, I have a vague sense that there's already a bug that I can't find searching through google or bugzilla ... maybe it's a RHEL bug I'm remembering?) Anyhow, attempting to bring this to upstream attention and get it addressed for real is obviously what needs to happen next, just wanting to be cautious to avoid somehow making things worse due to some technicality or mistaken premature bug-closure [not that I'm assuming such concerns are more relevant to any particular OSS community tbc :)] Trust me after all the work of that rather tedious bisection process I have no intention of dropping this on the floor -- I feel I've earned at least some of the glory :P (In reply to Greg Turner from comment #177) > (In reply to Sergei Trofimovich from comment #176) > > Filing bugs does not require any copyright assignments. Just file one on > > https://gcc.gnu.org/bugzilla/ and explain the details. > > ACK, I'll probably try to repro outside of Gentoo at this point, as I find > bug reports with the word "Gentoo" in them are understandably treated with a > bit of circumspection out there in non-Gentoo places... > FWIW, I think we have a pretty good relationship with GCC + glibc upstream, so I wouldn't worry too much, but of course, trying outside of Portage would be useful. > > Anyhow, attempting to bring this to upstream attention and get it addressed > for real is obviously what needs to happen next, just wanting to be cautious > to avoid somehow making things worse due to some technicality or mistaken > premature bug-closure [not that I'm assuming such concerns are more relevant > to any particular OSS community tbc :)] > I wouldn't worry too much. Just give as much information as you can. :) > Trust me after all the work of that rather tedious bisection process I have > no intention of dropping this on the floor -- I feel I've earned at least > some of the glory :P +1, huge thanks, even if this turns out to be spurious -- it's a lot of good work! (In reply to Greg Turner from comment #174) > Created attachment 718944 [details, diff] [details, diff] > revert-empty-class-copy-avoidance.patch > > I got fed up with this and git bisected it. The attached patch, applied to > =sys-devel/gcc-10.3.0-r1 and =sys-devel/gcc-11.1.0-r1 via > /etc/portage/patches enabled me to build =dev-libs/1.76.0-r1 50 times per > gcc without failure (whereas during the entire bisection process (14 splits! > ugh), affected gcc's always failed within six attempts. Not sure how many > confidence-sigmas that gives us, but at least one I'm sure. > > So this is very probably an actual work-around. Now: how can we turn this > into a useful bug that we can submit to gcc? I believe they have my > copyright assignment on file from way back. > > Also: w00t! Thank you very much for your work on this issue! This patch works for me using =sys-devel/gcc-10.3.0 to build =dev-libs/boost-1.76.0-r1 with a Threadripper 2920X and -march=native. Earlier stable versions of boost built with no issues on this system. However, building =dev-libs/boost-1.76.0-r1 always failed with stack smashing detected: even when trying the various suggested workarounds on this bug (including removing the march flag for gcc and boost). *** Bug 800203 has been marked as a duplicate of this bug. *** I last experienced this stack smash many months ago. Since then, I have successfully emerged various versions of boost with various versions of gcc (recently all 11.x) but yesterday got bit again - gcc-11.1.0-r1 (also -r2) and boost-1.76.0-r1 (which had previously emerged OK with gcc-11.1.0. Boost failed both when compiled by genkernel for the initramfs and also with a plain emerge. After applying the patch from Comment #174 to gcc-11.1.0-r2, both builds (emerge and genkernel) succeeded. Odd. I was never able to get around this, even with that patch, other than to limit gcc to version 9. For what it's worth, I was able to reproduce the bug in a gentoo VM, selecting "Epyc" as the CPU type. Please disregard the previous comments. The patch does work to fix the stack smashing build failures. Tested in VM and baremetal using Threadripper 1950x and sys-devel/gcc-11.1.0-r2. Thanks a lot for this! I was also having ICE issues building boost. Applying this patch to gcc-10.3.0-r2 allowed a successful compile. I am running gentoo on a VirtualBox image on Ryzen 7 1700. Thanks, this helped clear a headache. I can also report this patch fixed the ICE with Boost for me. Update In the end i was wrong: vtv didn't consistently make the problem go away for good, in fact it failed once. I've since added the patch (and dropped vtv) and the build has never failed again for over one month (i just won't say it consistently fixes the problem lol). (In reply to Greg Turner from comment #174) > Created attachment 718944 [details, diff] [details, diff] > revert-empty-class-copy-avoidance.patch > > I got fed up with this and git bisected it. The attached patch, applied to > =sys-devel/gcc-10.3.0-r1 and =sys-devel/gcc-11.1.0-r1 via > /etc/portage/patches enabled me to build =dev-libs/1.76.0-r1 50 times per > gcc without failure (whereas during the entire bisection process (14 splits! > ugh), affected gcc's always failed within six attempts. Not sure how many > confidence-sigmas that gives us, but at least one I'm sure. > > So this is very probably an actual work-around. Now: how can we turn this > into a useful bug that we can submit to gcc? I believe they have my > copyright assignment on file from way back. > > Also: w00t! This patch also works for me with gcc-10.3.0-r2 and march znver1. Thanks :-) I got hit by this again, but realized I had upgraded gcc to 11.2.0 without applying the patch. With the patch, 11.2.0 compiles boost 1.76.0-r1 without problems, both with emerge and with genkernel. Is there any chance of having this patch added to gentoo-sources? (In reply to Jack from comment #189) > Is there any chance of having this patch added to gentoo-sources? I think the problem right now is nobody who understands what it does has had the chance to evaluate it. It's pretty clearly not leading to wildly broken gcc outputs as, for example, I'm able to get into my desktop and do work on a system compiled with it. But there could be weird corner cases where gcc is relying on the behavior the patch reverts. We need to get attention to it upstream, a job I volunteered to perform, except that I then immediately proceeded to break the hardware I was using to reproduce the problem. I have just recently fixed it and plan to get that ball rolling this weekend. I guess I've been racking up points playing from the rough when I should have just taken a penalty shot, so sorry for that. (In reply to Greg Turner from comment #190) > this weekend (... three weeks later ...) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 (In reply to Sergei Trofimovich from comment #79) > I'm down to 1313 bytes of c++ :) Sergei, any chance you could be so kind as to share these 1313 bytes, assuming they are not lost to history? It might seem like, why bother, it's still so big? But it can hardly be worse than the huge xml_grammar thing we have otherwise. (In reply to Greg Turner from comment #192) > (In reply to Sergei Trofimovich from comment #79) > > I'm down to 1313 bytes of c++ :) > > Sergei, any chance you could be so kind as to share these 1313 bytes, > assuming they are not lost to history? > > It might seem like, why bother, it's still so big? But it can hardly be > worse than the huge xml_grammar thing we have otherwise. [adding slyfox's other email to CC]. (In reply to Greg Turner from comment #192) > (In reply to Sergei Trofimovich from comment #79) > > I'm down to 1313 bytes of c++ :) > > Sergei, any chance you could be so kind as to share these 1313 bytes, > assuming they are not lost to history? > > It might seem like, why bother, it's still so big? But it can hardly be > worse than the huge xml_grammar thing we have otherwise. I don't have it locally. Sorry. It's left on target machine and I don't have access to it anymore. I'm not sure how useful it is. The shorter example becomes the less probably it is to hit the bug: one needs to wait an hour before it hits the bug. Original big example is a lot better at triggering failure fast. *** Bug 827841 has been marked as a duplicate of this bug. *** I ran into this stack smashing ICE issue last night with latest Boost (1.77.0-r4) and GCC 11.2.0. Forcing vtv USE flag on solved the issue, but I know this is just a band-aid covering up the real issue. My system is a AMD Threadripper 1920X, mostly stable amd64. Reading through the comments makes it clear this is an issue affecting AMD processors, FWIW. (In reply to Alex Buell from comment #196) > I ran into this stack smashing ICE issue last night with latest Boost > (1.77.0-r4) and GCC 11.2.0. Forcing vtv USE flag on solved the issue, but I > know this is just a band-aid covering up the real issue. > > My system is a AMD Threadripper 1920X, mostly stable amd64. > > Reading through the comments makes it clear this is an issue affecting AMD > processors, FWIW. AS much as I hate to reply to myself, this doesn't affect my Intel Skylake laptop. A repeat failure now with dev-libs/boost-1.77.0, gcc-11.2.0.11 and my Ryzen processor. See my comments 154 and 157 above. I have carried out the same procedure as previously worked for me. Not that I am suggesting it is the correct procedure but I have not since had any adverse results. I have recompiled gcc with the 'pgo' flag set. That permits completion of the 'merge' of boost. Afterwards I re-compiled gcc minus the 'pgo' flag and continued with the remainder of other merges. I experienced no problem with the earier activity and hope not to with this! As others have mentioned before (e.g. comment #83), rather than hope the stars will align to allow boost to build with gcc, I suggest building boost with clang as a workaround. *** Bug 828468 has been marked as a duplicate of this bug. *** (In reply to Graham Young from comment #198) > A repeat failure now with dev-libs/boost-1.77.0, gcc-11.2.0.11 and my Ryzen > processor. See my comments 154 and 157 above. > > I have carried out the same procedure as previously worked for me. Not that > I am suggesting it is the correct procedure but I have not since had any > adverse results. > > I have recompiled gcc with the 'pgo' flag set. That permits completion of > the 'merge' of boost. Afterwards I re-compiled gcc minus the 'pgo' flag and > continued with the remainder of other merges. I experienced no problem with > the earier activity and hope not to with this! I can confirm. =dev-libs/boost-1.77.0-r4 failed to build for me also with gcc 11.2.0 and Ryzen (znver1). Have similar problem with dev-libs/boost on my VM when building gnome-light (GCC was rebuilt with -march=znver1 and -fomit-frame-pointer). Fixed it by building boost without -fomit-frame-pointer flag (temporarily remove it from make.conf). (In reply to viktorshahter from comment #202) > Have similar problem with dev-libs/boost on my VM when building gnome-light > (GCC was rebuilt with -march=znver1 and -fomit-frame-pointer). Fixed it by > building boost without -fomit-frame-pointer flag (temporarily remove it from > make.conf). Failed without -fomit-frame-pointer also. *** Bug 832665 has been marked as a duplicate of this bug. *** I got bit by this ICE trying to upgrade my kernel because of dirty pipe (boost-1.76.0, xml parser causes stack smashing ICE on gcc 10 and 11 but not 9). So I've worked around the issue temporarily by going back to gcc 9 to get my system back up and running (dirty pipe free). However, this issue still had me worried because there were lots of workarounds but nothing approaching a reason for the issue in the first place. I also didn't know why boost was the only thing on my system being affected by this. Like everyone affected, I am running a Zen/Zen+ CPU. I have confirmed the bug on two cpus: - Threadripper 1920X (thought GCC 10 was just buggy at the time) - Threadripper 2970WX My USE is "-O2 -pipe -march=znver1" (more system information can be provided if desired). Reading through the comments (especially the one about stale fsbase and it being hard to consistently trigger) I started to get the distinct impression that this is probably a CPU errata of some kind. So I found the "revision guide" that AMD put out on Fam 17h. In it there are three errata that directly deal with stale data. They are: - 1021 (Load Operation May Receive Stale Data From Older Store Operation) - 1091 (4K Address Boundary Crossing Load Operation May Receive Stale Data) - 1095 [Potential Violation of Read Ordering In Lock Operation In SMT (Simultaneous Multithreading) Mode] I don't think it is 1095 or 1091 because the document states that those only apply to Threadripper and EPYC processors. 1021 though applies to _all_ Zen/Zen+ Ryzen CPUs. While AMD is very vague on the actual set of "timing conditions", I have a strong suspicion that 1021 is probably the cause of this. More specifically, this set of "timing conditions" is probably exacerbated by any new optimizations introduced for znver1 by gcc-10 and later. Especially if the patch that Greg Turner made seems to fix the issue at the expense of less optimal code. This would also explain why removing the -march=znver1 flag works for some people (not sure if it is a universal one). Thanks for looking into this. After the recent bump of GCC to 11.2.1_p20220115 I rebuilt boost (1.78.0-r2) again with -O2 -march=native (TR1950X) to see if Greg's patch still works (I am still using it), and apparently it does, I did not get an ICE. However, I had happy accidents before, when it just went through without failure but other times it still failed (with the same settings). Not sure if the patch harms optimization much, but I'd rather have a slightly slower binary that works than ICEs in the compilation :-). (In reply to Greg Turner from comment #174) > Created attachment 718944 [details, diff] [details, diff] > revert-empty-class-copy-avoidance.patch > > I got fed up with this and git bisected it. The attached patch, applied to > =sys-devel/gcc-10.3.0-r1 and =sys-devel/gcc-11.1.0-r1 via > /etc/portage/patches enabled me to build =dev-libs/1.76.0-r1 50 times per > gcc without failure (whereas during the entire bisection process (14 splits! > ugh), affected gcc's always failed within six attempts. Not sure how many > confidence-sigmas that gives us, but at least one I'm sure. > > So this is very probably an actual work-around. Now: how can we turn this > into a useful bug that we can submit to gcc? I believe they have my > copyright assignment on file from way back. > > Also: w00t! For the sake of statistics, the patch is holding fine for me so far. Not a single failure in these many months. Also FWIW another package failing similarly was (is?) kicad. It also never failed to build again since. Thanks! Yep, the patch has been working fine for me too all this time. Hello, I’m sorry to tell you that this patch doesn’t work on my (up-to-date, znver1) system. Boost was previously installed without issue. But during an update, last week, boost failed to re-emerge the same version. Which is what led me here and to trying this patch. I put it in /etc/portage/patches/sys-devel/gcc/, re-emerged gcc, verified it got applied, then re-emerged boost, and it still got terminated with “stack smashing detected”. Should I open a new bug? What other information do you need? (In reply to Navid Zamani from comment #209) > Hello, I’m sorry to tell you that this patch doesn’t work on my (up-to-date, > znver1) system. > > Boost was previously installed without issue. But during an update, last > week, boost failed to re-emerge the same version. Which is what led me here > and to trying this patch. > > I put it in /etc/portage/patches/sys-devel/gcc/, re-emerged gcc, verified it > got applied, then re-emerged boost, and it still got terminated with “stack > smashing detected”. > > Should I open a new bug? What other information do you need? No, no need to open a new bug. The patch isn't guaranteed to work. It just reduces the chances of it happening for some people. Ultimately, it's almost certainly a CPU issue, and/or the GCC developers need some way to reliably reproduce it. (In reply to Sam James from comment #210) > (In reply to Navid Zamani from comment #209) > > Hello, I’m sorry to tell you that this patch doesn’t work on my (up-to-date, > > znver1) system. > > > > Should I open a new bug? What other information do you need? > > No, no need to open a new bug. The patch isn't guaranteed to work. It just > reduces the chances of it happening for some people. Although I can't strictly confirm this, I have seen what looked like a regression once since applying the patch. I don't think I hallucinated it but it was just once. So perhaps you are indeed an early victim of a new era where this patch no longer has the impact it once did. If so we'll see more activity in this bug soon. Somebody would have to be the first to notice or report it, perhaps they are you. But I would also strongly consider the possibility that you have some other gcc being used, than the one you thought, or that you got very unlucky. Navid, try something like, i=0; j=0; while ((i++ < 100)); do emerge -1O dev-libs/boost || ((j++)); done; echo "${j} out of ${i} failed." Before and after the patch, and you'll (very slowly) get a better idea of how the odds are playing out in your particular silicon and software environment. (In reply to Sam James from comment #210) > Ultimately, it's almost certainly a CPU issue, and/or the GCC developers > need some way to reliably reproduce it. Can I help there, in some way? Because I can reliably reproduce it. As in: I haven’t gotten to to compile ever since. (I try once a week, when I update the system.) If I was given a script to run, that could collect whatever info is needed, I could run it, since this is an unfinished installation anyway. (E.g. if somebody wanted to try gdb or probe the CPU or such.) (In reply to Greg Turner from comment #211) > But I would also strongly consider the possibility that you have some other > gcc being used, than the one you thought, or that you got very unlucky. I used gcc-11.3.0 today. I just checked. > Navid, try something like, > > i=0; j=0; while ((i++ < 100)); do emerge -1O dev-libs/boost || ((j++)); > done; echo "${j} out of ${i} failed." I haven’t gotten it to build even once in the last weeks. So I can already narrow it down to being less likely than 1 in 10 to work. With gcc-11.3.0 and the patch that is. But likely reliably never. > Before and after the patch, and you'll (very slowly) get a better idea of > how the odds are playing out in your particular silicon and software > environment. I’m currently trying out different versions of gcc, in the hope that it might not happen there. But I would like a proper fix instead of a “works sometimes, if the stars align right” though. ;) So since I’m definitely not the only one with a znver1 CPU, … can you help me find anyone who’s interested in debugging this? I don’t know much about the GCC developer community. Sorry that this is just another "me too" and doesn't provide much additional information. I today hit this on a machine in our office. That machine has been running for at least 2 years now and it must have had boost for quite the same time. Today when upgrading boost from 1.78.0-r2 to 1.79.0 using gcc 11.3.0 that issue occured. Downgrading gcc to 10.3.1_p20211126 didn't help. However, setting USE="debug" for gcc:11 "fixed" the problem. Linux 5.15.41-gentoo using a hand-crafted kernel config (= no genkernel), AMD Ryzen Threadripper 2990WX. *** Bug 851054 has been marked as a duplicate of this bug. *** Can confirm that 'debug' USE flag on sys-devel/gcc-11.3.0 does the job. See my earlier comments 166,170 above. IT may be of interest that I have been running boost-1.73.0 compiled by gcc with the gpo flag set for about a year, and have experiencd no problems. The gpo flag was removed after the merge. The recent update to boost-1.79.0 saw a return of the failure, which I resoved in the manner previously (and patiently!) carried out, and I am now hoping to get another year before the next update or a resolution is found! I will notify if I get any problems in the next month. Created attachment 784100 [details] znver1-gcc-bug.conf — Make portage use clang/lld. Hey everyone, I managed to work around this bug. By telling portage to compile boost with clang (llvm). Of course, clang and llvm are one very heavy dependency. And there are possible issues with ABI compatibility (essentially potentially forcing other packages to be built with clang too), as documented at: https://wiki.gentoo.org/wiki/Clang But it works perfectly fine, as far as I can tell. Here’s how to do it: 1. emerge clang lld 2. Download znver1-gcc-bug.conf and put it into /etc/portage/env/ 3. Put the packages where the bug occurs into /etc/portage/package.env/znver1-gcc-bug e.g.: dev-libs/boost znver1-gcc-bug.conf My Ryzen 3100 builds it just fine but my Threadripper 1920X does not. I see I have already had this issue the last time with Boost and got it to build. Doesn't work this time around. I might try compiling it with -znver2 on my 1920X, just to see what happens. Finally got around to trying znver2 whilst compiling Boost, that didn't work. Still got the stack smashing issue. (In reply to Alex Buell from comment #221) > Finally got around to trying znver2 whilst compiling Boost, that didn't > work. Still got the stack smashing issue. A 1920x should be znver1... I have a 2950x and it is also znver1. A 3100 should be znver2 though... That said, I ran into this some time ago as well, wound up dropping -march entirely on gcc. (In reply to Navid Zamani from comment #218) > Of course, clang and llvm are one very heavy dependency. And there are > possible issues with ABI compatibility (essentially potentially forcing > other packages to be built with clang too), as documented at: > https://wiki.gentoo.org/wiki/Clang Clang should be ABI compatible with GCC. If it isn't, it's a (serious) bug. The ABI incompatibility you're thinking of is probably libstdc++ vs libcxx/libc++. Clang's usage of libcxx is not enabled by default. It is safe to use Clang selectively as you wish. Created attachment 784139 [details]
Environment workaround for znver1+gcc+boost
I can confirm the workaround from comment #224 works for me with gcc 11.3 and boost 1.79 My system is a Threadripper 1950X. (In reply to Greg Turner from comment #174) > Created attachment 718944 [details, diff] [details, diff] > revert-empty-class-copy-avoidance.patch Hi, the inevitable has happened :> As of =sys-devel/gcc-12.1.1_p20220625 Greg's patch, who's served me well for over a year, no longer applies. I didn't look at the failed hunks just yet as I'm just back from holidays and the work backlog is insane, but I'll try to find some time this week. Created attachment 790052 [details, diff] revert-empty-class-copy-avoidance-gcc12.patch (In reply to acab from comment #226) > (In reply to Greg Turner from comment #174) > > Created attachment 718944 [details, diff] [details, diff] [details, diff] > > revert-empty-class-copy-avoidance.patch > > Hi, the inevitable has happened :> > > As of =sys-devel/gcc-12.1.1_p20220625 Greg's patch, who's served me well for > over a year, no longer applies. > I didn't look at the failed hunks just yet as I'm just back from holidays > and the work backlog is insane, but I'll try to find some time this week. gcc-12 has renamed several files from .c to .cc, patches often just need the filenames to be edited Haven't tried building this and don't know if it still helps, but attached updated patch either way (identical beside filenames and rebased on gcc-12.1.1_p20220702). (In reply to Ionen Wolkens from comment #227) > Haven't tried building this and don't know if it still helps, but attached > updated patch either way (identical beside filenames and rebased on > gcc-12.1.1_p20220702). Patch applies fine, thanks a lot for updating it. Gcc-12 also built seemingly alright. And last but not least I've built boost successfully 3 times. All anecdotal, I know, so just a FYI... Thanks again *** Bug 873898 has been marked as a duplicate of this bug. *** I have a problem that #gentoo said was likely this bug (it looks very similar). On a ryzen 7 2700x, using gcc 11.3.0 (and 10.3.1) libreoffice fails to compile with a stack smashing error. I found the file it was failing on (always the same line even), and wrote a simple reproducer. It was probabilistic, probably around 25% of the time. I then replace the mother board and CPU with the exact same model motherboard and CPU. I discovered that the issue disappeared. Other that the motherboard and CPU, all the hardware remained the same. Every tentatively this looks like it might be a old-age failure, or just a faulty chip. Anyhow hope this data point is helpful. Just another data point - I just upgraded to gcc-11.3.1_p20221209 and got the stack smashing error emerging boost-1.80.0-r1, but a second try worked fine. boost-1.80.0-r1 had previously been emerge by gcc-11.3.0 with the patch. Just in case it is of interest, I can report that I have repeated the procedure I followed in comment-217 above with boost-1.81.0-r1 and gcc-11.3.1_p20221209. Tedious, but it works. For the people affected by this bug: 1. Do you have the latest BIOS/AGESA/microcode installed? 2. Have you compiled the kernel in vanilla mode, avoiding the config option MZEN and not using any -march=znverX in CFLAGS? (In reply to David Seifert from comment #233) > For the people affected by this bug: > > 1. Do you have the latest BIOS/AGESA/microcode installed? > 2. Have you compiled the kernel in vanilla mode, avoiding the config option > MZEN and not using any -march=znverX in CFLAGS? AMD Threadripper 2970WX on ASRock X399 Taichi, latest BIOS applied (v4.01) Kernel does not have MZEN enabled -march=znver1 in use I have just compiled Boost without CLANG and it was successful. First time in years that it's built cleanly with GCC. Thanks, Alex I have had no problems with a standard merge since gcc-12.2.1 and boost-1.82 Don't know what changed but I recently checked and repeated builds with gcc-12.3.1 and gcc-13.2.0 work fine, no more ICE. When I had this problem it was guaranteed, boost would absolutely not build. I have been applying the revert-empty-class-copy-avoidance.patch all this time and never had any troubles since I started applying it about two years ago. I am using -march=native, which probably is roughly equivalent to -march=znver1 for me (Threadripper 1950X)? I have not dared to build GCC and boost without this patch so far, but the latest comments make me hopeful to try that. Just merged gcc 13.2.1_p20230826 without trying to apply the patch. Switched to it and rebuilt boost and updated a few other packages. No issues so far. Looking good! |
