From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id CD75C385828B; Thu, 18 Apr 2024 13:18:27 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD75C385828B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713446307;
	bh=yzy7wm01jtvxFKKTZmZ6Evc+Kc3gRoTxr7fU+FVi2KI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=e0f61zYoiRObrJf5S0OMkJmnShIA4kYmQqQwNyUMbSvLVqoqBzJ21Ikf4u5MHQEiu
	 H69aSWUguvGSnObr1Rv8RkXgRzk3I9XzSfAaFQYTlxnWiAWH9eDUQ2ox2Temw31/w9
	 djwmGIO8UHKC9N3OBS7PaFLBQymFntP0U9tuBA2E=
From: "muecker at gwdg dot de" <gcc-bugzilla@gcc.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, 18 Apr 2024 13:18:27 +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: P2
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: <bug-114574-4-MH3WAeAsfk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114574-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114574-4@http.gcc.gnu.org/bugzilla/>
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: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114574

--- Comment #30 from Martin Uecker <muecker at gwdg dot de> ---
Am Donnerstag, dem 18.04.2024 um 11:57 +0000 schrieb jakub at gcc dot gnu.o=
rg:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114574
>=20
> --- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to uecker from comment #28)
> > I do not fully understand yet what happens for may_alias, but it if we =
later
> > complete the struct with the may_alias attribute it seems we would also=
 need
> > to update the previously created pointer so that it has
> > TYPE_REF_CAN_ALIAS_ALL.  Setting TYPE_STRUCTURAL_EQUALITY for incomplete
> > structs also for pre-C23 seems to fix the assertion failure, but I am n=
ot
> > sure if this fixes the underlying bug.
>=20
> Certainly that may_alias case isn't specific to just C, C++ behaves the s=
ame,
> and I'd just say don't do that, you can always put the may_alias attribut=
e on
> the forward declaration of the struct if all pointers to it are supposed =
to
> alias.

The problem I was referring to is the ICE, not that we get from
assertions in the middle end, not that some pointers constructed
from the incomplete type without the attribute may not have this=C2=A0
property, cf. PR114493

For C++, the example does not ICE. I haven't looked at
what the C++ FE does differently, I simply observed that setting
TYPE_STRUCTURAL_EQUALITY as the patch does for C23 also seems to
fix (?) this ICE (but only for C23 if guarded by flag_iso_c23).

I haven't had time to look more into this.=20

Martin=