Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 724314

Summary: sys-devel/gcc-10.1.0-r1 stack corruption in cp_gimplify_expr() when building dev-libs/boost-1.73.0 on AMD Ryzen (znver1)
Product: Gentoo Linux Reporter: myloveyuxuan
Component: Current packagesAssignee: Gentoo Toolchain Maintainers <toolchain>
Status: CONFIRMED ---    
Severity: major CC: acab, agrigo2001, barehuggy, brezensalzer, dennis, devel, flockmock, gcyoung, gentoo, gentoo, gmt, goeland86, herrtimson, ilmostro7, ionen, jasonrc, jstein, kilgorephotoshop, kirill.shkrogalev, m.piwek, meks, neil, ninpo, ostroffjh, richbergert, sam, samurai.no.dojo, slyich, soap, stig, user.light.man
Priority: Normal    
Version: unspecified   
Hardware: AMD64   
OS: Linux   
URL: https://wiki.gentoo.org/wiki/Project:Toolchain/724314-gcc-10-and-znver1
See Also: https://bugs.gentoo.org/show_bug.cgi?id=730406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: Build Log
preprocessed file of xml_grammar.c
The preprocessed file of xml_grammar.cpp
The output of `emerge --info sys-devel/gcc sys-libs/glibc`
The error messages when I try to compile xml_grammar.cpp for five times
Debug log
telegram build log
telegram source where stack smashing occurs
telegram-emerge-info
Emerge order of packages
build.log for boost-1.75 for Intel CPU with gentoo-lto
new debug logs when I found out where the ICE happened.
new debug logs when I found a pointer with invalid value.
emerge --info
boost-1.76.0-r1.build.log
revert-empty-class-copy-avoidance.patch

Description myloveyuxuan 2020-05-20 09:56:58 UTC
Portage seems failed to build `dev-libs/boost-1.73.0` when I type `emerge --ask kde-plasma/plasma-meta`.

Reproducible: Always

Steps to Reproduce:
1.Build a new Gentoo System
2.Try to type emerge `emerge kde-plasma/plasma-meta`
Actual Results:  
Build failed
Comment 1 myloveyuxuan 2020-05-20 09:58:43 UTC
Created attachment 640550 [details]
Build Log

Build log generated when it built failed
Comment 2 myloveyuxuan 2020-05-20 09:59:20 UTC
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
Comment 3 David Seifert gentoo-dev 2020-06-02 08:59:01 UTC
Paging in slyfox, who might be able to help, given that this is an ICE.
Comment 4 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-02 17:11:29 UTC
"""
    "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?
Comment 5 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-03 09:04:55 UTC
(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.
Comment 6 myloveyuxuan 2020-06-08 13:51:05 UTC
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
Comment 7 myloveyuxuan 2020-06-08 13:51:39 UTC
--- 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]
Comment 8 myloveyuxuan 2020-06-08 13:58:21 UTC
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]
Comment 9 myloveyuxuan 2020-06-08 13:58:57 UTC
--- 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]
Comment 10 myloveyuxuan 2020-06-08 13:59:11 UTC
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 ()
Comment 11 myloveyuxuan 2020-06-08 14:05:08 UTC
Created attachment 643972 [details]
preprocessed file of xml_grammar.c
Comment 12 myloveyuxuan 2020-06-08 14:22:19 UTC
(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
Comment 13 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-08 18:04:34 UTC
(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!
Comment 14 myloveyuxuan 2020-06-09 12:57:07 UTC
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`
Comment 15 myloveyuxuan 2020-06-09 12:57:40 UTC
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 ()
Comment 16 myloveyuxuan 2020-06-09 13:10:10 UTC
(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 .
Comment 17 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-09 23:30:06 UTC
Can you also check that sys-apps/memtest86+ or similar test does not report memory errors on your machine?
Comment 18 myloveyuxuan 2020-06-10 09:59:04 UTC
(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.
Comment 19 myloveyuxuan 2020-06-10 13:21:32 UTC
  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.
Comment 20 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-10 18:07:57 UTC
(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'
Comment 21 myloveyuxuan 2020-06-11 10:57:20 UTC
(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.
Comment 22 myloveyuxuan 2020-06-11 10:58:49 UTC
Created attachment 644360 [details]
The output of `emerge --info sys-devel/gcc sys-libs/glibc`
Comment 23 myloveyuxuan 2020-06-11 11:04:22 UTC
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.
Comment 24 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-11 18:55:58 UTC
(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.
Comment 25 myloveyuxuan 2020-06-12 02:51:39 UTC
(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.
Comment 26 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-12 21:47:02 UTC
(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?
Comment 27 myloveyuxuan 2020-06-13 04:53:16 UTC
(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
Comment 28 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-14 07:56:45 UTC
(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.
Comment 29 myloveyuxuan 2020-06-22 03:32:55 UTC
Created attachment 645596 [details]
Debug log
Comment 30 myloveyuxuan 2020-06-22 03:38:36 UTC
(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
Comment 31 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-22 07:09:29 UTC
(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.
Comment 32 myloveyuxuan 2020-06-22 10:30:47 UTC
(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.
Comment 33 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-22 21:34:15 UTC
(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!
Comment 34 Brian Evans Gentoo Infrastructure gentoo-dev 2020-06-23 13:52:55 UTC
*** Bug 729308 has been marked as a duplicate of this bug. ***
Comment 35 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-24 21:10:19 UTC
Let's own the bug by toolchain@.
Comment 36 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-24 22:28:02 UTC
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.
Comment 37 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-25 22:52:43 UTC
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.
Comment 38 user.light.man 2020-06-26 08:57:10 UTC
I tried to compile with MAKEOPTS=-j1, but it crashes anyway
Comment 39 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-26 09:14:08 UTC
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 ?
Comment 40 user.light.man 2020-06-26 12:44:17 UTC
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
Comment 41 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-26 16:06:59 UTC
(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?
Comment 42 user.light.man 2020-06-26 16:11:12 UTC
the second, successfully compiled
Comment 43 user.light.man 2020-06-26 17:53:30 UTC
stack smashing happens again, but now in a program what I write
Comment 44 user.light.man 2020-06-26 18:02:48 UTC
oh no, it is not related with this problem, sorry
Comment 45 myloveyuxuan 2020-06-27 12:56:38 UTC
(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.
Comment 46 Sergei Trofimovich (RETIRED) gentoo-dev 2020-06-27 13:07:54 UTC
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.
Comment 47 user.light.man 2020-06-27 15:05:51 UTC
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
Comment 48 Sergei Trofimovich (RETIRED) gentoo-dev 2020-07-03 20:55:39 UTC
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.
Comment 49 myloveyuxuan 2020-07-05 10:22:17 UTC
(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.
Comment 50 user.light.man 2020-07-05 10:44:14 UTC
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
Comment 51 Sergei Trofimovich (RETIRED) gentoo-dev 2020-07-05 19:09:46 UTC
(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.
Comment 52 user.light.man 2020-07-06 09:00:57 UTC
I made these steps, it still fails
Comment 53 myloveyuxuan 2020-07-07 04:38:32 UTC
  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.
Comment 54 Stig Nielsen 2020-07-07 05:48:01 UTC
Hi, just to make sure. You had only the debug flag enabled or where the other flags as well?
Comment 55 Sergei Trofimovich (RETIRED) gentoo-dev 2020-07-07 06:29:27 UTC
(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.
Comment 56 myloveyuxuan 2020-07-07 06:37:34 UTC
(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.
Comment 57 myloveyuxuan 2020-07-07 06:39:11 UTC
(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
Comment 58 Sergei Trofimovich (RETIRED) gentoo-dev 2020-07-21 23:12:29 UTC
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
Comment 59 myloveyuxuan 2020-09-04 15:13:49 UTC
Seems that upstream has fixed it.
Comment 60 Sergei Trofimovich (RETIRED) gentoo-dev 2020-09-04 19:36:31 UTC
(In reply to myloveyuxuan from comment #59)
> Seems that upstream has fixed it.

Do you have a link to the fix?
Comment 61 myloveyuxuan 2020-09-07 09:24:07 UTC
(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
Comment 62 Sergei Trofimovich (RETIRED) gentoo-dev 2020-09-07 13:46:33 UTC
(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
Comment 63 Greg Turner 2020-10-31 11:49:06 UTC
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.
Comment 64 Sergei Trofimovich (RETIRED) gentoo-dev 2020-10-31 13:29:06 UTC
There are still no known fixes for this bug. We still need a reproducer to debug it effectively.
Comment 65 Greg Turner 2020-10-31 15:06:08 UTC
(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...?
Comment 66 Greg Turner 2020-11-04 11:01:32 UTC
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.
Comment 67 Greg Turner 2020-11-07 07:13:51 UTC
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"....
Comment 68 goeland86 2020-11-15 19:43:35 UTC
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.
Comment 69 Sergei Trofimovich (RETIRED) gentoo-dev 2020-11-15 20:14:53 UTC
(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.
Comment 70 goeland86 2020-11-16 22:30:45 UTC
@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.
Comment 71 Sergei Trofimovich (RETIRED) gentoo-dev 2020-11-21 10:16:22 UTC
(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
Comment 72 Greg Turner 2020-11-21 11:01:47 UTC
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
Comment 73 Sergei Trofimovich (RETIRED) gentoo-dev 2020-11-22 10:37:31 UTC
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.
Comment 74 Sergei Trofimovich (RETIRED) gentoo-dev 2020-11-22 11:45:45 UTC
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.
Comment 75 Sergei Trofimovich (RETIRED) gentoo-dev 2020-11-28 21:56:05 UTC
*** Bug 730406 has been marked as a duplicate of this bug. ***
Comment 76 Bernd Feige 2020-12-10 08:29:55 UTC
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...
Comment 77 younky.yang 2020-12-10 10:51:24 UTC
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):
Comment 78 Sergei Trofimovich (RETIRED) gentoo-dev 2020-12-13 12:12:31 UTC
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.
Comment 79 Sergei Trofimovich (RETIRED) gentoo-dev 2020-12-15 22:45:39 UTC
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.
Comment 80 younky.yang 2020-12-17 08:06:04 UTC
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.
Comment 81 Jack 2020-12-17 16:19:04 UTC
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.
Comment 82 younky.yang 2020-12-20 11:09:38 UTC
Same error with gcc-10.2-r4 with kernel 5.10.1
Comment 83 Bluey The Dog 2020-12-23 15:51:44 UTC
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"
Comment 84 younky.yang 2020-12-24 05:35:04 UTC
(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.
Comment 85 Sergei Trofimovich (RETIRED) gentoo-dev 2020-12-26 10:03:36 UTC
*** Bug 761685 has been marked as a duplicate of this bug. ***
Comment 86 Greg Turner 2020-12-27 22:29:37 UTC
(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).
Comment 87 ninpo 2021-01-09 11:20:44 UTC
Created attachment 682072 [details]
telegram build log
Comment 88 ninpo 2021-01-09 11:21:25 UTC
Created attachment 682075 [details]
telegram source where stack smashing occurs

Source file telegram build stack smashes on
Comment 89 ninpo 2021-01-09 11:22:02 UTC
Created attachment 682078 [details]
telegram-emerge-info

emerge info for telegram build
Comment 90 ninpo 2021-01-09 11:25:00 UTC
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
Comment 91 ninpo 2021-01-09 11:48:43 UTC
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.
Comment 92 Greg Turner 2021-01-09 17:56:10 UTC
(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.

:(
Comment 93 ninpo 2021-01-10 13:31:59 UTC
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.
Comment 94 meks 2021-01-13 18:37:41 UTC
Created attachment 682741 [details]
build.log for boost-1.75 for Intel CPU with gentoo-lto
Comment 95 meks 2021-01-13 18:45:23 UTC
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.
Comment 96 ninpo 2021-01-13 19:42:37 UTC
(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..
Comment 97 meks 2021-01-13 20:44:22 UTC
(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.
Comment 98 Sergei Trofimovich (RETIRED) gentoo-dev 2021-01-14 07:28:01 UTC
(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.
Comment 99 Jan C Peters 2021-03-07 22:13:04 UTC
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.
Comment 100 Greg Turner 2021-03-08 01:21:59 UTC
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.
Comment 101 Sergei Trofimovich (RETIRED) gentoo-dev 2021-03-08 01:37:55 UTC
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.
Comment 102 Greg Turner 2021-03-08 09:51:16 UTC
(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.
Comment 103 Sergei Trofimovich (RETIRED) gentoo-dev 2021-03-08 18:14:30 UTC
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).
Comment 104 Sam James archtester gentoo-dev Security 2021-03-16 14:44:14 UTC
*** Bug 776595 has been marked as a duplicate of this bug. ***
Comment 105 Ionen Wolkens gentoo-dev 2021-03-31 07:34:18 UTC
*** Bug 779439 has been marked as a duplicate of this bug. ***
Comment 106 Sam James archtester gentoo-dev Security 2021-04-03 13:53:34 UTC
*** Bug 779886 has been marked as a duplicate of this bug. ***
Comment 107 Austin Kilgore 2021-04-03 17:28:26 UTC
Recompiling gcc actually fixed it for me.
Comment 108 Neil Stone 2021-04-05 12:25:27 UTC
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.
Comment 109 Marco Scardovi (scardracs) 2021-04-10 06:40:58 UTC
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
Comment 110 Marco Scardovi (scardracs) 2021-04-10 06:42:50 UTC
Just to be clear: dev-libs/boost-1.75.0
Comment 111 Isaac Crawford 2021-04-11 07:50:37 UTC
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)
Comment 112 Neil Stone 2021-04-11 07:54:26 UTC
(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...
Comment 113 Isaac Crawford 2021-04-11 08:01:20 UTC
(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.
Comment 114 Greg Turner 2021-04-11 08:28:46 UTC
(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 :)
Comment 115 Isaac Crawford 2021-04-11 16:51:18 UTC
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.
Comment 116 samurai.no.dojo 2021-04-15 11:54:51 UTC
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")
Comment 117 samurai.no.dojo 2021-04-15 11:56:41 UTC
(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"
Comment 118 Neil Stone 2021-04-29 08:22:43 UTC
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.
Comment 119 Sergei Trofimovich (RETIRED) gentoo-dev 2021-04-29 10:38:20 UTC
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.
Comment 120 Amel Hodzic 2021-05-08 22:29:53 UTC
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.
Comment 121 Amel Hodzic 2021-05-09 00:09:59 UTC
FWIW, I booted into kernels 5.10.16-gentoo and 5.9.15-gentoo to try to rebuild.  The problem persists.
Comment 122 Adrian 2021-05-09 23:42:10 UTC
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.
Comment 123 Ionen Wolkens gentoo-dev 2021-05-10 02:13:49 UTC
*** Bug 789087 has been marked as a duplicate of this bug. ***
Comment 124 myloveyuxuan 2021-05-10 03:54:50 UTC
(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.
Comment 125 myloveyuxuan 2021-05-10 04:09:54 UTC
(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.
Comment 126 Adrian 2021-05-10 05:10:55 UTC
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.
Comment 127 myloveyuxuan 2021-05-10 10:08:24 UTC
(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.
Comment 128 myloveyuxuan 2021-05-10 12:28:25 UTC
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.
Comment 129 myloveyuxuan 2021-05-10 17:31:29 UTC
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.
Comment 130 Adrian 2021-05-10 23:49:51 UTC
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.
Comment 131 Amel Hodzic 2021-05-11 03:14:51 UTC
(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?
Comment 132 Adrian 2021-05-11 08:37:37 UTC
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.
Comment 133 myloveyuxuan 2021-05-11 10:18:04 UTC
(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.
Comment 134 myloveyuxuan 2021-05-11 14:37:10 UTC
(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.
Comment 135 myloveyuxuan 2021-05-11 17:49:24 UTC
Created attachment 707136 [details]
new debug logs when I found a pointer with invalid value.
Comment 136 myloveyuxuan 2021-05-11 17:54:24 UTC
(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.
Comment 137 Amel Hodzic 2021-05-13 01:54:00 UTC
(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.
Comment 138 Adrian 2021-05-13 10:36:08 UTC
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.
Comment 139 Joseph 2021-05-13 15:01:31 UTC
-O2 -march=native and -O3 both with and without -march=native didn't work for me. -Ofast -pipe (no -march=native) did.
Comment 140 Amel Hodzic 2021-05-14 03:29:02 UTC
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.
Comment 141 Adrian 2021-05-14 03:52:48 UTC
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?
Comment 142 darthm 2021-05-28 14:13:47 UTC
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
Comment 143 acab 2021-05-31 14:05:42 UTC
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
Comment 144 Sergei Trofimovich (RETIRED) gentoo-dev 2021-05-31 19:19:04 UTC
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); `
Comment 145 Jan C Peters 2021-05-31 20:13:48 UTC
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.
Comment 146 acab 2021-05-31 23:31:00 UTC
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
Comment 147 acab 2021-06-01 09:47:46 UTC
(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
Comment 148 Jan C Peters 2021-06-02 07:01:18 UTC
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.
Comment 149 Greg Turner 2021-06-03 00:28:32 UTC
(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 150 Graham Young 2021-06-03 14:23:08 UTC
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;
 *
Comment 151 Graham Young 2021-06-03 14:36:46 UTC
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
Comment 152 Jan C Peters 2021-06-03 16:26:25 UTC
(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.
Comment 153 Joseph 2021-06-04 12:37:50 UTC
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.
Comment 154 Graham Young 2021-06-05 07:41:43 UTC
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.
Comment 155 scott 2021-06-05 19:02:10 UTC
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
Comment 156 Jason C 2021-06-05 23:09:40 UTC
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)
Comment 157 Graham Young 2021-06-06 12:37:50 UTC
Following Jason Collisons example I re-executed the necessary emerges without the
lto flag, and can confirm I found it was not required.
Comment 158 Jason C 2021-06-06 14:46:40 UTC
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.
Comment 159 acab 2021-06-06 14:55:39 UTC
(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...
Comment 160 Jason C 2021-06-06 20:41:11 UTC
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?
Comment 161 Sergei Trofimovich (RETIRED) gentoo-dev 2021-06-07 21:20:17 UTC
(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.
Comment 162 myloveyuxuan 2021-06-08 03:21:46 UTC
(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.
Comment 163 goeland86 2021-06-08 05:18:26 UTC
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
Comment 164 Jan C Peters 2021-06-08 07:53:12 UTC
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.
Comment 165 Graham Young 2021-06-08 13:28:53 UTC
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.
Comment 166 Graham Young 2021-06-08 20:02:07 UTC
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.
Comment 167 Sergei Trofimovich (RETIRED) gentoo-dev 2021-06-08 21:31:32 UTC
(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).
Comment 168 Greg Turner 2021-06-08 22:12:05 UTC
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.
Comment 169 Greg Turner 2021-06-08 22:18:48 UTC
(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.
Comment 170 Graham Young 2021-06-09 08:10:19 UTC
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".
Comment 171 Sumit Khanna 2021-06-11 22:38:59 UTC
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
Comment 172 Sumit Khanna 2021-06-11 22:39:36 UTC
Created attachment 715356 [details]
boost-1.76.0-r1.build.log
Comment 173 Greg Turner 2021-06-17 06:01:07 UTC
(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.
Comment 174 Greg Turner 2021-06-25 04:13:50 UTC
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!
Comment 175 Greg Turner 2021-06-25 06:58:14 UTC
(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*
Comment 176 Sergei Trofimovich (RETIRED) gentoo-dev 2021-06-25 06:59:35 UTC
Filing bugs does not require any copyright assignments. Just file one on https://gcc.gnu.org/bugzilla/ and explain the details.
Comment 177 Greg Turner 2021-06-25 07:45:06 UTC
(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
Comment 178 Sam James archtester gentoo-dev Security 2021-06-25 21:54:29 UTC
(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!
Comment 179 iamcodebass 2021-06-29 18:17:05 UTC
(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).
Comment 180 Sam James archtester gentoo-dev Security 2021-07-04 00:48:46 UTC
*** Bug 800203 has been marked as a duplicate of this bug. ***
Comment 181 Jack 2021-07-13 19:52:49 UTC
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.
Comment 182 Amel Hodzic 2021-07-17 18:32:28 UTC
Odd.  I was never able to get around this, even with that patch, other than to limit gcc to version 9.
Comment 183 Amel Hodzic 2021-07-17 18:35:40 UTC
For what it's worth, I was able to reproduce the bug in a gentoo VM, selecting "Epyc" as the CPU type.
Comment 184 Amel Hodzic 2021-07-18 11:08:49 UTC
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!
Comment 185 Dave Bender 2021-07-26 12:36:35 UTC
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.
Comment 186 Jan C Peters 2021-07-28 15:34:17 UTC
I can also report this patch fixed the ICE with Boost for me.
Comment 187 acab 2021-08-01 16:02:00 UTC
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).
Comment 188 hackrevdd 2021-08-05 15:50:33 UTC
(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 :-)
Comment 189 Jack 2021-08-14 16:48:44 UTC
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?
Comment 190 Greg Turner 2021-08-14 18:32:40 UTC
(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.
Comment 191 Greg Turner 2021-09-05 08:04:04 UTC
(In reply to Greg Turner from comment #190)
> this weekend

(... three weeks later ...)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
Comment 192 Greg Turner 2021-09-07 00:44:55 UTC
(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.
Comment 193 Sam James archtester gentoo-dev Security 2021-09-07 00:46:04 UTC
(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].
Comment 194 Sergei Trofimovich 2021-09-07 06:48:41 UTC
(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.