https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115502
--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-14 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:37bbd2c1667c70387f5fa6b52f461d57a204229d commit r14-10366-g37bbd2c1667c70387f5fa6b52f461d57a204229d Author: Jakub Jelinek <ja...@redhat.com> Date: Tue Jun 25 08:35:56 2024 +0200 c: Fix ICE related to incomplete structures in C23 [PR114930] Here is a version of the c_update_type_canonical fixes which passed bootstrap/regtest. The non-trivial part is the handling of the case when build_qualified_type (TYPE_CANONICAL (t), TYPE_QUALS (x)) returns a type with NULL TYPE_CANONICAL. That should happen only if TYPE_CANONICAL (t) == t, because otherwise c_update_type_canonical should have been already called on the other type. c, the returned type, is usually x and in that case it should have TYPE_CANONICAL set to itself, or worst for whatever reason x is not the right canonical type (say it has attributes or whatever disqualifies it from check_qualified_type). In that case either it finds some pre-existing type from the variant chain of t which is later in the chain and we haven't processed it yet (but then get_qualified_type moves it right after t in: /* Put the found variant at the head of the variant list so frequently searched variants get found faster. The C++ FE benefits greatly from this. */ tree t = *tp; *tp = TYPE_NEXT_VARIANT (t); TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (mv); TYPE_NEXT_VARIANT (mv) = t; return t; optimization), or creates a fresh new type using build_variant_type_copy, which again places the new type right after t: /* Add the new type to the chain of variants of TYPE. */ TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m); TYPE_NEXT_VARIANT (m) = t; TYPE_MAIN_VARIANT (t) = m; At this point we want to make c its own canonical type (i.e. TYPE_CANONICAL (c) = c;), but also need to process pointers to it and only then return back to processing x. Processing the whole chain from c again could be costly, we could have hundreds of types in the chain already processed, and while the loop would just quickly skip them for (tree x = t, l = NULL_TREE; x; l = x, x = TYPE_NEXT_VARIANT (x)) { if (x != t && TYPE_STRUCTURAL_EQUALITY_P (x)) ... else if (x != t) continue; it feels costly. So, this patch instead moves c from right after t to right before x in the chain (that shouldn't change anything, because clearly build_qualified_type didn't find any matches in the chain before x) and continues processing the c at that position, so should handle the x that encountered this in the next iteration. We could avoid some of the moving in the chain if we processed the chain twice, once deal only with x != t && TYPE_STRUCTURAL_EQUALITY_P (x) && TYPE_CANONICAL (t) == t && check_qualified_type (t, x, TYPE_QUALS (x)) types (in that case set TYPE_CANONICAL (x) = x) and once the rest. There is still the theoretical case where build_qualified_type would return a new type and in that case we are back to the moving the type around and needing to handle it though. 2024-06-25 Jakub Jelinek <ja...@redhat.com> Martin Uecker <uec...@tugraz.at> PR c/114930 PR c/115502 gcc/c/ * c-decl.cc (c_update_type_canonical): Assert t is main variant with 0 TYPE_QUALS. Simplify and don't use check_qualified_type. Deal with the case where build_qualified_type returns TYPE_STRUCTURAL_EQUALITY_P type. gcc/testsuite/ * gcc.dg/pr114574-1.c: Require lto effective target. * gcc.dg/pr114574-2.c: Likewise. * gcc.dg/pr114930.c: New test. * gcc.dg/pr115502.c: New test. (cherry picked from commit 777cc6a01d1cf783a36d0fa67ab20f0312f35d7a)
