From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 224B9384AB6E; Fri, 3 May 2024 07:11:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 224B9384AB6E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1714720271; bh=tTeX6dvltWaWMbYIKIJPJxs0JfEA/uFNtcQM+FbCFks=; h=From:To:Subject:Date:In-Reply-To:References:From; b=DenJBDe0cJCTzf8jqJYyIV+UVb4LXnAfk++YnsCm0ceC1jbfWqdFDm1wchxaWuFMw zlT76OR0p1/779q2UatnSbNf88Dxyx1sus48pbDKr9CZ1HpMSPKBEUtWmS3zUt6gFd YdA4sYAZuyxxOTiee4IEENk2LUkqh4A3+2D+6g/s= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114931] [14/15 regression] ICE in get_alias_set when building tcl with -std=c23 Date: Fri, 03 May 2024 07:11:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114931 --- Comment #6 from Richard Biener --- When we build the pointer type there's already (gdb) p to_type $18 =3D (gdb) p to_type->type_common.canonical=20 $15 =3D (gdb) p to_type->type_common.canonical->type_common.canonical=20 $17 =3D the interesting bit is that build_function_type when doing else if (any_noncanonical_p) TYPE_CANONICAL (t) =3D build_function_type (TYPE_CANONICAL (value_type), canon_argtypes); to build the canonical type gets an already present function type through type_has_canon that has TYPE_STRUCTURAL_EQUALITY_P set. So somehow it is inconsistent with itself here - at the time we build that function type maybe_canonicalize_argtypes sets any_structural_p so it seems we set TYPE_CANONICAL "late" on some types? In particular both the pointer and struct type have TYPE_STRUCTURAL_EQUALITY_P set. It might be tempting to do the following which fixes the testcase but then this simply means we'll never find types with structural equality in the hash (note we insert those when they still have themselves as canonical typ= e). In some sense TYPE_STRUCTURAL_EQUALITY_P means we have not properly unified types so unifying even less shouldn't make it much worse. It would be still interesting to see why we build the function type with original "incomplete" argument types. diff --git a/gcc/tree.cc b/gcc/tree.cc index 83f3bf306af..35bb7713e1f 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -6109,6 +6109,10 @@ type_cache_hasher::equal (type_hash *a, type_hash *b) || TYPE_MODE (a->type) !=3D TYPE_MODE (b->type))) return false; + if (TYPE_STRUCTURAL_EQUALITY_P (a->type) + !=3D TYPE_STRUCTURAL_EQUALITY_P (b->type)) + return false; + switch (TREE_CODE (a->type)) { case VOID_TYPE: debugging patch: diff --git a/gcc/tree.cc b/gcc/tree.cc index 83f3bf306af..35bb7713e1f 100644 --- a/gcc/tree.cc +++ b/gcc/tree.cc @@ -7520,8 +7524,11 @@ build_function_type (tree value_type, tree arg_types, if (any_structural_p) SET_TYPE_STRUCTURAL_EQUALITY (t); else if (any_noncanonical_p) + { TYPE_CANONICAL (t) =3D build_function_type (TYPE_CANONICAL (value_type= ), canon_argtypes); + gcc_assert (TYPE_CANONICAL (TYPE_CANONICAL (t)) =3D=3D TYPE_CANONICAL = (t)); + } if (!COMPLETE_TYPE_P (t)) layout_type (t);=