[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #13 from Alexander Monakov --- Sergei Trofimovich made substantial progress on diagnosing this on Gentoo side, and according to his findings the crash is due to reading stack canary from a wrong location. This indicates that the bug is not in GCC, but in the CPU or maybe the kernel. Please see comments 73 and 74 in the Gentoo bugreport: https://bugs.gentoo.org/724314#c73
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #12 from Martin Liška --- I tried bootstrapping the current tip of gcc-11 branch with -O2 -march=native on my model name : AMD Ryzen 7 2700X Eight-Core Processor but I can't reproduce the ICE on the provided boost test-case :/
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
If it is really a buffer overflow in cp_gimplify_expr (which is weird, there
aren't many arrays in there nor anything else that could result in that, there
is
tree *data[4] = { NULL, NULL, NULL, NULL };
but you aren't compiling with -fopenmp and it also uses just those 4 entries),
then perhaps asan built gcc might be more reliable at detecting it.
Of course, if it is miscompiled cp_gimplify_expr, it might be something else...
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #10 from Greg Turner --- If you find yourself not readily reproducing, let me know I suspect a pregenerated gentoo prefix might be a nice "drag-and-drop" way to get someone up and running with a fully working reproduction. Of course it'll take a bunch of time to create one. But once done, interested parties could just shove it into their userspace sandboxes and stop scratching their heads. Otherwise, the nondeterminism sort of leads to awful quagmires where you just keep scratching your head and saying "...or maybe I just got lucky..." followed by an unsatisfying period of reading about probability-density-functions and confidence-intervals on Wikipedia :)
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #9 from Greg Turner --- Never mind, corrected version is quite equivalent: --- xml_grammar_gcc_-E.cpp 2021-09-06 01:38:48.125773266 -0700 +++ xml_grammar_gcc_-E-try2.cpp 2021-09-06 01:49:24.384875598 -0700 @@ -1,4 +1,5 @@ # 0 "libs/serialization/src/xml_grammar.cpp" +# 1 "/var/tmp/portage/dev-libs/boost-1.76.0-r1/work/boost_1_76_0-abi_x86_64.amd64//" # 0 "" # 0 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 :)
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #8 from Greg Turner --- Actually please ignore that one pending replacement, I probably generated it wrong...
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #7 from Greg Turner --- Created attachment 51412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51412=edit xml_grammar_gcc_-E.cpp.xz preproc boost cpp file that tends to trigger failure
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #6 from Martin Liška --- > I would think you'd want the one generated on the bugged compiler, not mine. > But iiuc I guess they'd be identical, assuming all is well until > gimplification? Yes, that's identical, it's a source file.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #5 from Greg Turner --- (In reply to Martin Liška from comment #4) > (use -E option) to this bug. Note Oh, /that/ kind of preprocessed! That's easy... I thought it was some kind of re-usable pre-compiled header file thing, sorry. I would think you'd want the one generated on the bugged compiler, not mine. But iiuc I guess they'd be identical, assuming all is well until gimplification? For a start I'll get you what comes out of my patched gcc, I'll just need a moment.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 --- Comment #4 from Martin Liška --- > > 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 Please attach a pre-processed source file (use -E option) to this bug. Note I don't use Gentoo Linux, so I can't easily build the boost package.
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206
--- Comment #3 from Greg Turner ---
(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
[Bug middle-end/102206] amd zen hosts running zen-optimized gcc: gimplification ICE after r10-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102206 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2021-09-06 --- Comment #2 from Martin Liška --- 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?
