ICE initially noticed by Alexander Weber in https://bugs.gentoo.org/822690. Here is the reduced test, fails on both gcc-12 and gcc-11.2.0. Note: it needs a gch header. //$ cat archiveBuilder.cpp #include "precompiled.hpp" void *operator new(unsigned long, void *__p) { return __p; } #define MEMORY_TYPES_DO(f) f(mtNone, ) enum MEMFLAGS {}; #define MEMORY_TYPE_SHORTNAME(type, human_readable) MEMFLAGS type; MEMORY_TYPES_DO(MEMORY_TYPE_SHORTNAME) struct GrowableArrayView { GrowableArrayView(int *, int, int); }; int *GrowableArrayWithAllocator_data; struct GrowableArrayWithAllocator : GrowableArrayView { GrowableArrayWithAllocator(int initial_max) : GrowableArrayView(GrowableArrayWithAllocator_data, initial_max, 0) { for (int i = 0; i < initial_max; i++) new (&GrowableArrayWithAllocator_data[i]) int(); } }; struct GrowableArrayMetadata { GrowableArrayMetadata(MEMFLAGS); }; struct GrowableArray : GrowableArrayWithAllocator { GrowableArrayMetadata _metadata; GrowableArray(int initial_max) : GrowableArrayWithAllocator(initial_max), _metadata(mtNone) {} }; struct SourceObjList { SourceObjList(); }; SourceObjList::SourceObjList() { GrowableArray(128 * 1024); } $ rm -rf ph $ mkdir -p ph $ touch precompiled_.hpp # create empty file $ ./xg++ -B. -O3 -march=opteron -fcheck-new -c precompiled_.hpp -o ph/precompiled.hpp.gch $ ./xg++ -B. -O3 -march=opteron -fcheck-new -Iph -c archiveBuilder.cpp -o a.o during GIMPLE pass: aprefetch archiveBuilder.cpp: In constructor ‘SourceObjList::SourceObjList()’: archiveBuilder.cpp:28:1: internal compiler error: in gimple_build_call, at gimple.c:267 28 | SourceObjList::SourceObjList() { GrowableArray(128 * 1024); } | ^~~~~~~~~~~~~ 0xd2845f gimple_build_call(tree_node*, unsigned int, ...) gcc/gimple.c:267 0x12880c8 emit_mfence_after_loop gcc/tree-ssa-loop-prefetch.c:1300 0x12880c8 mark_nontemporal_stores gcc/tree-ssa-loop-prefetch.c:1359 0x12880c8 loop_prefetch_arrays gcc/tree-ssa-loop-prefetch.c:1955 0x12880c8 tree_ssa_prefetch_arrays() gcc/tree-ssa-loop-prefetch.c:2031 0x1288be9 execute gcc/tree-ssa-loop-prefetch.c:2097 $ ./xg++ -v Using built-in specs. COLLECT_GCC=./xg++ Target: x86_64-pc-linux-gnu Configured with: ../configure --disable-multilib --disable-bootstrap --with-native-system-header-dir=<<NIX>>-glibc-2.33-59-dev/include --prefix=/home/slyfox/dev/git/gcc-build/__td__ CFLAGS='-O1 -ggdb3' CXXFLAGS='-O1 -ggdb3' LDFLAGS='-O1 -ggdb3' Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20220104 (experimental) (GCC)
call = gimple_build_call (FENCE_FOLLOWING_MOVNT, 0); config/i386/i386.h:#define FENCE_FOLLOWING_MOVNT x86_mfence /* Fence to use after loop using movnt. */ tree x86_mfence; There is no GTY on that in config/i386/i386.c.
Created attachment 52124 [details] archiveBuilder.cpp
This should fix the issue: apinski@xeond:~/src/upstream-gcc/gcc/gcc/config/i386$ git diff i386.h diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h index f027608eefa..3ac0f698ae2 100644 --- a/gcc/config/i386/i386.h +++ b/gcc/config/i386/i386.h @@ -486,7 +486,7 @@ extern unsigned char ix86_prefetch_sse; /* Fence to use after loop using storent. */ -extern tree x86_mfence; +extern GTY(()) tree x86_mfence; #define FENCE_FOLLOWING_MOVNT x86_mfence /* Once GDB has been enhanced to deal with functions without frame
(In reply to Andrew Pinski from comment #3) > This should fix the issue: > apinski@xeond:~/src/upstream-gcc/gcc/gcc/config/i386$ git diff i386.h > diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h > index f027608eefa..3ac0f698ae2 100644 > --- a/gcc/config/i386/i386.h > +++ b/gcc/config/i386/i386.h > @@ -486,7 +486,7 @@ extern unsigned char ix86_prefetch_sse; > > /* Fence to use after loop using storent. */ > > -extern tree x86_mfence; > +extern GTY(()) tree x86_mfence; > #define FENCE_FOLLOWING_MOVNT x86_mfence > > /* Once GDB has been enhanced to deal with functions without frame This fix helps to build openjdk17 on patched gcc. Thank you!
Mine then.
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>: https://gcc.gnu.org/g:d243f4009d8071b734df16cd70f4c5d09a373769 commit r12-6274-gd243f4009d8071b734df16cd70f4c5d09a373769 Author: Andrew Pinski <apinski@marvell.com> Date: Wed Jan 5 22:00:07 2022 +0000 Fix target/103910: missing GTY on x86_mfence causing PCH usage to ICE With -O3 -march=opteron, a mfence builtin is added after the loop to say the nontemporal stores are no longer needed. This all good without precompiled headers as the function decl that is referneced by x86_mfence is referenced in another variable but with precompiled headers, x86_mfence is all messed up and the decl was GC'ed away. This fixes the problem by marking x86_mfence as GTY to save/restore during precompiled headers just like most other variables in the header file. Committed as obvious after a bootstrap/test on x86_64-linux-gnu. gcc/ChangeLog: PR target/103910 * config/i386/i386.h (x86_mfence): Mark with GTY.
Fixed. The bug has been latent since r0-81404 (4.3.0 release). I doubt many people are testing on opteron any mores but if someone wants to backport the fix I am ok with that too.
(In reply to Andrew Pinski from comment #7) > Fixed. The bug has been latent since r0-81404 (4.3.0 release). I doubt many > people are testing on opteron any mores but if someone wants to backport the > fix I am ok with that too. More people than I expected hit this downstream in Gentoo. Your commit seems to apply cleanly and work on top of the 11 branch. Could somebody apply it if possible please?
> (In reply to Andrew Pinski from comment #7) (and thank you to both you and slyfox!)
(In reply to Sam James from comment #8) > More people than I expected hit this downstream in Gentoo. Your commit seems > to apply cleanly and work on top of the 11 branch. Could somebody apply it > if possible please? DEF_TUNE (X86_TUNE_SOFTWARE_PREFETCHING_BENEFICIAL, "software_prefetching_beneficial", m_K6_GEODE | m_ATHLON_K8 | m_AMDFAM10 | m_BDVER | m_BTVER) Someone would have hit this a long time ago, in GCC 4.3.0 or latter.
(In reply to Andrew Pinski from comment #10) > Someone would have hit this a long time ago, in GCC 4.3.0 or latter. My point was that some software has recently started building with PCH by default and hence it's only appeared now and I was surprised at the number of people who were affected. I understand the bug isn't new, it's just been exposed by a change in the ecosystem.
(In reply to Sam James from comment #11) > (In reply to Andrew Pinski from comment #10) > > Someone would have hit this a long time ago, in GCC 4.3.0 or latter. > > My point was that some software has recently started building with PCH by > default and hence it's only appeared now and I was surprised at the number > of people who were affected. I understand the bug isn't new, it's just been > exposed by a change in the ecosystem. Could you provide some more info on the software that has recently started building with PCH by default? There has been some talk of wanting to rip PCH out of GCC at some point, but if there's software out there actually depending on it, that could be useful info for the argument that PCH ought to be kept.
I personally build PCHs in my build systems, as a test that the header files are self-contained. It has proved useful to me. But I could live without it if you insist on removing it. Just a data point.