From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 178B23858C56; Thu, 4 Apr 2024 07:21:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 178B23858C56 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1712215300; bh=duHuZ8GayeEvCCppCg1T8jg/nV6gASyjH7EfiS21QqI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=foM5UltqAZPz8ntwUMuQMd0t9h9QJTtHYOd3kHeew7b+kAhG4khwAf2YiMOhIAgFo UjphW1qdnjflYqOSn/6z2rpc3XO0Y4p2G6VNC56cEQoc+INFKsxNMw6gHVxlGKVlnC eU/7usBVwQvD/MMxAIvIiz8xMEKiGSkPbHuOajeA= From: "jakub at gcc dot gnu.org" 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:21:38 +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: jakub at gcc dot gnu.org 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 #12 from Jakub Jelinek --- 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 the= n). See how e.g. cp/typeck.cc (comptypes) will do structural_comptypes if at le= ast 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 i= t. So, having TYPE_CANONICAL NULL should just be slower, but not wrong (as lon= g as comptypes etc. works correctly). Having TYPE_CANONICAL non-NULL and not actually matching could cause type comparisons to think types are the same = when they aren't or vice versa. Now, when you set TYPE_CANONICAL on completion of the flag_isoc23 aggregate= s, you could surely also update TYPE_CANONICAL of the variant types using build_qualified_type and perhaps pointers too, just to handle the common ca= se.=20 But unlike the case where the TYPE_CANONICAL of the aggregate TYPE_MAIN_VAR= IANT 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.=