Unforunately I don't have data going back to the start of GCC 11 and I also don't know any fortran so no idea how to go about minimizing this.. But Gamess in SPECCPU 2006 fails with an ICE: 0x6ca753 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../.././gcc/tree.c:9905 0x753033 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../.././gcc/tree.h:3413 0x753033 compare_base_decls(tree_node*, tree_node*) ../.././gcc/alias.c:2145 0xdaa9c3 ptr_deref_may_alias_decl_p ../.././gcc/tree-ssa-alias.c:227 0x17f67bb dr_may_alias_p(data_reference const*, data_reference const*, loop*) ../.././gcc/tree-data-ref.c:2769 0x17f693f initialize_data_dependence_relation(data_reference*, data_reference*, vec<loop*, va_heap, vl_ptr>) ../.././gcc/tree-data-ref.c:2843 0x17fb13b compute_all_dependences(vec<data_reference*, va_heap, vl_ptr>, vec<data_dependence_relation*, va_heap, vl_ptr>*, vec<loop*, va_heap, vl_ptr>, bool) ../.././gcc/tree-data-ref.c:5391 0x1800807 compute_data_dependences_for_loop(loop*, bool, vec<loop*, va_heap, vl_ptr>*, vec<data_reference*, va_heap, vl_ptr>*, vec<data_dependence_relation*, va_heap, vl_ptr>*) ../.././gcc/tree-data-ref.c:5868 0xd6b307 tree_predictive_commoning_loop ../.././gcc/tree-predcom.c:3211 0xd6b307 tree_predictive_commoning() ../.././gcc/tree-predcom.c:3333 when built with -Ofast -fomit-frame-pointer -flto --param ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=80 -fno-inline-functions-called-once Removing any of these options seems to make it go away.
I can reproduce that and I'm working on a reduction of the issue..
Hm, is it really a GCC 11 regression? I see another ICE with the oldest revision I have: 9d55066c88b4c276(09 Oct 2014 07:40)(fxcoudert@gcc.gnu.org) scflib.fppized.f: In function 'symh.constprop': scflib.fppized.f:3780:0: internal compiler error: in expand_assignment, at expr.c:4857 460 H(KL) = T(K,L) ^ Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[1]: *** [/tmp/cceDDRMT.mk:8: /tmp/ccGK5ftT.ltrans2.ltrans.o] Error 1
Hmm it compiles for me with GCC 10.2 built from e939674db6fda62a98675d20b95175ec4ba81140
So what are base1/base2 when the assert triggers? Also try a checking build which should ICE a bit earlier in the assert: gcc_checking_assert (DECL_P (base1) && DECL_P (base2)); but the call chain looks sufficiently protected - so maybe it's a GC issue of SCEV data...
So just in case the following fixes it we've nailed it (somewhere I have a verifier written...) diff --git a/gcc/tree-predcom.c b/gcc/tree-predcom.c index b1d6e63559c..2f41ad222a0 100644 --- a/gcc/tree-predcom.c +++ b/gcc/tree-predcom.c @@ -3326,6 +3326,7 @@ tree_predictive_commoning (void) class loop *loop; unsigned ret = 0, changed = 0; + scev_reset (); initialize_original_copy_tables (); FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST) if (optimize_loop_for_speed_p (loop))
(In reply to Richard Biener from comment #5) > So just in case the following fixes it we've nailed it (somewhere I have a > verifier written...) > > diff --git a/gcc/tree-predcom.c b/gcc/tree-predcom.c > index b1d6e63559c..2f41ad222a0 100644 > --- a/gcc/tree-predcom.c > +++ b/gcc/tree-predcom.c > @@ -3326,6 +3326,7 @@ tree_predictive_commoning (void) > class loop *loop; > unsigned ret = 0, changed = 0; > > + scev_reset (); > initialize_original_copy_tables (); > FOR_EACH_LOOP (loop, LI_ONLY_INNERMOST) > if (optimize_loop_for_speed_p (loop)) Unfortunately, it doesn't help.
So we're getting a CONST_DECL into compare_base_decls which doesn't have RTL but DECL_REGISTER requires DECL_WITH_RTL. One fix would be diff --git a/gcc/alias.c b/gcc/alias.c index 1cb702be2ce..3f01c7072d2 100644 --- a/gcc/alias.c +++ b/gcc/alias.c @@ -2142,7 +2142,9 @@ compare_base_decls (tree base1, tree base2) /* If we have two register decls with register specification we cannot decide unless their assembler names are the same. */ - if (DECL_REGISTER (base1) + if (HAS_RTL_P (base1) + && HAS_RTL_P (base2) + && DECL_REGISTER (base1) && DECL_REGISTER (base2) && HAS_DECL_ASSEMBLER_NAME_P (base1) && HAS_DECL_ASSEMBLER_NAME_P (base2) but I wonder if we instead want VAR_P (base1) && DECL_HARD_REGISTER (base1) ? So I'm testing the following which also fixes the testcase diff --git a/gcc/alias.c b/gcc/alias.c index 1cb702be2ce..f6d7a1791c4 100644 --- a/gcc/alias.c +++ b/gcc/alias.c @@ -2142,10 +2142,10 @@ compare_base_decls (tree base1, tree base2) /* If we have two register decls with register specification we cannot decide unless their assembler names are the same. */ - if (DECL_REGISTER (base1) - && DECL_REGISTER (base2) - && HAS_DECL_ASSEMBLER_NAME_P (base1) - && HAS_DECL_ASSEMBLER_NAME_P (base2) + if (VAR_P (base1) + && VAR_P (base2) + && DECL_HARD_REGISTER (base1) + && DECL_HARD_REGISTER (base2) && DECL_ASSEMBLER_NAME_SET_P (base1) && DECL_ASSEMBLER_NAME_SET_P (base2)) {
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>: https://gcc.gnu.org/g:371f0b990f2bbf638b44da27cf6fc5f86e0d6d4e commit r11-3385-g371f0b990f2bbf638b44da27cf6fc5f86e0d6d4e Author: Richard Biener <rguenther@suse.de> Date: Wed Sep 23 10:07:37 2020 +0200 middle-end/97162 - fix ICE when building gamess This appropriately guards the check for a hard register in compare_base_decls which otherwise ICEs when passed a CONST_DECL. 2020-09-23 Richard Biener <rguenther@suse.de> PR middle-end/97162 * alias.c (compare_base_decls): Use DECL_HARD_REGISTER and guard with VAR_P.
Thanks Richi! I can confirm the testcase builds with that patch :)
Fixed.