From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0C2073858D34; Thu, 4 Apr 2024 07:57:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0C2073858D34 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712217434; bh=Fm+n9159Numf2uFEvtKqU2diyxt/wQeq2RYqB3fytzQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Q1WF+WA7m/2Y7FiT68Vv4/M/QanZyA/GHCoUAGgxmosMlKd4OBazZWKzDy5ml7sKK blhNHt1TVtXlB6A6JUnaihNr5p2ZjFQxRnFMBILsfGn6Cx/FJGOVBNTlMNzEjQ0BIl nrLMY/n7EBbr4+fD/yBmqVvXWf6krafdX1I4UBE4= From: "muecker at gwdg dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763 Date: Thu, 04 Apr 2024 07:57:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: muecker at gwdg dot de X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 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=3D114574 --- Comment #14 from Martin Uecker --- (In reply to Jakub Jelinek from comment #12) > Not an expert on TYPE_CANONICAL, but my understanding is that non-NULL > TYPE_CANONICAL is just an optimization to speed up type comparisons (but = it > seems c-typeck.cc doesn't actually use that, so it is mainly middle-end > then). > See how e.g. cp/typeck.cc (comptypes) will do structural_comptypes if at > least one TYPE_CANONICAL is NULL (aka TYPE_STRUCTURAL_EQUALITY_P), and > otherwise at least without checking will rely on TYPE_CANONICAL comparison > and that is it. > So, having TYPE_CANONICAL NULL should just be slower, but not wrong (as l= ong > as comptypes etc. works correctly). Having TYPE_CANONICAL non-NULL and n= ot > actually matching could cause type comparisons to think types are the same > when they aren't or vice versa. >=20 > Now, when you set TYPE_CANONICAL on completion of the flag_isoc23 > aggregates, you could surely also update TYPE_CANONICAL of the variant ty= pes > using build_qualified_type and perhaps pointers too, just to handle the > common case. But unlike the case where the TYPE_CANONICAL of the aggrega= te > TYPE_MAIN_VARIANT would be initially different, you wouldn't need to chase > down everything, including TYPE_CANONICAL on FUNCTION_TYPE which have > pointers to array type of array type of pointer of pointer of qualified > pointer to the aggregate etc., just the common things. > And setting TYPE_CANONICAL just based on the tag would be also wrong, if = one > can define struct S { int s; }; in one scope and struct S { int a, b; }; = in > another scope and those types are supposed to be different. According to my understanding, setting based on tag would form larger equivalence classes, so should give correct code but suboptimal aliasing analysis. There are two general issues I see here. 1.) The middle end idea of type compatibility is not necessarily the same as the language semantics. In particular type compatibility in C is not based = on mutual equivalence, so any mechanism based on forming equivalence classes u= sing TYPE_CANONICAL can only be an approximation (which to be correct, must be l= ess precise than the language semantics).=20 2.) If compatibility relationship changes for types (as it the case when completing types, then we either have to use an equivalence class that does= not need to change (e.g. based on tags) or only use structural equivalency, or upgrade structural equivalency to the equivalency class for the completed = type if this is allowed.=