https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
--- Comment #3 from Greg Turner <g...@be-evil.net> --- (In reply to Martin Liška from comment #2) > Can you please show how do you configure and build GCC (gcc -v). > And can you please attach a pre-processed boost source (and command-line > used) that can reproduce the issue? Gentoo does all this heavy lifting. Some of these things I am blissfully ignorant of although I'm happy to drill into the build process and drag some artifacts over here if that will help. I don't have an affected gcc, since I apply the patch to my one system capable of repro-ing the bug. I might also have a laptop capable of reproing, I haven't tried. But here's a gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/11.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-11.2.0/work/gcc-11.2.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/11.2.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/g++-v11 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/11.2.0/python --enable-languages=c,c++,go,jit,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.2.0 p1' --disable-esp --enable-libstdcxx-time --enable-host-shared --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --enable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (Gentoo 11.2.0 p1) Without the patch the same configuration would of course enable me to repro; I assume the above would be 100% the same. Note that this doesn't even capture the most important part of the equation*: $ portageq envvar CFLAGS -march=znver1 -mtune=znver1 -O2 -pipe -g tbh I guess I am not sure if I ever confirmed this applied to 11.2, perhaps it fixed it and I never noticed. But I very highly doubt it, this bug has been quite persistent. As for boost, I don't think any special configuration or version is required to make it happen ... [time passes...] got it, the specific build step that tends** to cause the failure is: /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 Anyhow since we know for sure my system repro's the bug , here are the use-flags affecting my boost build: dev-libs/boost-1.76.0-r1:0/1.76.0::gentoo USE="bzip2 doc icu lzma nls python threads tools zlib zstd -context -debug -mpi -numpy -static-libs" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python3_8 python3_9 -python3_10" This passes "${OPTIONS[@]}" to boost's jam invocation which on my system ends up looking like: declare -a OPTIONS=( [0]="gentoorelease" [1]="-j52" [2]="-q" [3]="-d+2" [4]="pch=off" [5]="-sICU_PATH=/usr" [6]="--without-mpi" [7]="--without-context" [8]="--without-coroutine" [9]="--without-fiber" [10]="--without-stacktrace" [11]="--boost-build=/usr/share/boost-build/src" [12]="--layout=system" [13]="threading=multi" [14]="link=shared" [15]="-sNO_BZIP2=0" [16]="-sNO_LZMA=0" [17]="-sNO_ZLIB=0" [18]="-sNO_ZSTD=0" ) See comment 12-14 of the Gentoo bug for some talk/examples of preproc headers. I do not have an affected compiler at my disposal and am not even sure how all this preproc header stuff works... let me know if that's really a serious need & I'll build a bugged compiler & hit the books or w/e is required to figure out the preproc header things. -- * if using Gentoo or Gentoo-prefix to repro this (possibly the path of least confusion ime) the use flag "custom-cflags" must be set on sys-devel/gcc to repro (otherwise the c{,xx}flags do not actually apply to gcc). ** rarely, I think I observed similar gimplification failures elsewhere in the build during my git bisect. Maybe twice during the ~24 builds that would have occurred using affected gcc's during my bisect, based on a guesstimated 4 mean builds before failure for bugged compilers and assuming 50% of my 12-step git bisect was bugged...?
