From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 14A46385E836; Fri, 3 May 2024 07:56:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 14A46385E836 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1714723006; bh=0gd5XAbFfZnhKHy553ixtRBmFT+t5UsEs7cA5faciQs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BovMJmthThK7EKFjvlJrTS5EuKmEO7fl9sMorIlusEMqAki3SnAs4YDVpJ/6pCWs6 OaW3cr7msTUznFvV3xYB0oBYkSaWVH+z3lJ0Ju95zhMMkptzNMLwARiiIlOWK7uQyZ 95QQWkgszWukVStRy+G9BIoYMgjDWgJecXGKrz8o= 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:56:45 +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 #10 from Richard Biener --- (In reply to Jakub Jelinek from comment #9) > Do you really need to hash it on TYPE_CANON, rather than just on whether = the > type is > TYPE_STRUCTURAL_EQUALITY_P or not? It's enough for the testcases here, I didn't try to convince myself it's sa= fe but of course it's better than what we do right now. So we can try that as well. > I'm worried that always computing the TYPE_CANON before calling > type_hash_canon is going to be quite expensive, while just figuring out if > it should have TYPE_STRUCTURAL_EQUALITY_P or not should be cheaper. If it > should have > TYPE_STRUCTURAL_EQUALITY_P, we'd SET_TYPE_STRUCTURAL_EQUALITY, otherwise = set > TYPE_CANONICAL (t) =3D t; (I think that is what we generally get from > make_node), look up > and recompute TYPE_CANONICAL if TYPE_CANONICAL (t) =3D=3D t. I'd like to make it obvious at least that we only alter TYPE_CANONICAL if we were the one building 't' in the first place. The layouting of types also seems to be redundant now as that's done by type_hash_canon. Luckily there are not too many callers. It's a bit late for 14.1, so we can refactor things on trunk and then backp= ort later.=