From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A39003857BA2; Tue, 28 Nov 2023 08:02:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A39003857BA2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701158568; bh=PUO3te2AFRi8IcIyQ7AvKbd+Dv+ubmEWrpywfTkWVpQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YHZIO3bKtRXz/IxBVyvGkyZBaBlEREG1U09QBA0djMD/r7s2KNlJnJ5BhyruUDZV7 V03D6+RxtItDPOfOAo08yYjwAlIzs4YKAiZK7osNSxPd/8nP4hWh5yzgEx6YqYfNmM RXq2QLysAQeX/jC8gZLWpY21xxifLF3JHAbxhhuU= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/112716] LTO optimization with struct with variable size Date: Tue, 28 Nov 2023 08:02:44 +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: alias, wrong-code 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: --- 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=3D112716 --- Comment #8 from Richard Biener --- (In reply to uecker from comment #7) > (In reply to rguenther@suse.de from comment #6) > > On Mon, 27 Nov 2023, muecker at gwdg dot de wrote: > >=20 > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112716 > > >=20 > > > --- Comment #5 from Martin Uecker --- > > > It works (and is required to work) for other types, e.g. > > >=20 > > > [[gnu::noinline,gnu::noipa]] > > > int foo(void *p, void *q) > > > { > > > int n =3D 5; > > > int (*p2)[n] =3D p; > > > (*p2)[0] =3D 1; > > > bar(q); > > > return (*p2)[0]; > > > } > > >=20 > > > void bar(void* q) > > > {=20=20=20=20=20=20=20 > > > int n =3D 5; > > > int (*q2)[n] =3D q; > > > (*q2)[0] =3D 2; > > > } > > >=20 > > > One could argue that there is a weaker requirement for having an obje= ct of type > > > int[n] present than for struct { int x[n]; } because we do not access= the array > > > directly but it decays to a pointer. (but then, other languages have = array > > > assignment, so why does the middle-end care about this C peculiarity?= )=20 > >=20 > > So in theory we could disregard the VLA-sized components for TBAA > > which would make the access behaved as if it were a int * indirect acce= ss. > > I think if you write it as array as above that's already what happens. >=20 > What does "disregard the VLA-sized component" mean? Hmm, it wouldn't help I guess. The problem in the end will be disambiguation of aggregate copies, not so much the accesses to the array elements of a VLA component. > For full interoperability I think one either has to assign=20 > equivalence classes for structs by ignoring the sizes of all > fields of array type (not just VLA) and also the offsets=20 > for the following struct members, or, alternately, one has > to give alias set 0 to structs with VLA fields. The later > seems preferable and is what I have included in the current > version of my patch for C23 for structs with VLA fields=20 > (but we could also decide to not support full ISO C rules for > such structs, of course) Using alias set 0 of course works (also with LTO). > >=20 > > Note that even without LTO when you enable inlining you'd expose two > > different structures with two different alias-sets, possibly leading > > to wrong-code (look at the RTL expansion dump and check alias-sets). >=20 > Yes, for pre C23 this is true for all structs even without VLA. > But for C23 this changes. >=20 > The main case where the GNU extension is interesting and useful is > when the VLA field is at the end. So at least for this case it would > be nice to have a solution. So what's the GNU extension here? VLA inside structs are not a C thing? I suppose if they were then C23 would make only the "abstract" types compatible but the concrete types (actual 'n') would only be compatible when 'n' is the same? I think the GNU extension is incomplete, IIRC you can't have foo (int n, struct bar { int x; int a[n]; } b) -> struct bar { return bar; } and there's no way to 'declare' bar in a way that it's usable across functions. So I'm not sure assigning C23 "semantics" to this extension is very useful. Your examples are awkward workarounds for an incomplete language extension.=