https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to uecker from comment #7) > (In reply to rguent...@suse.de from comment #6) > > On Mon, 27 Nov 2023, muecker at gwdg dot de wrote: > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716 > > > > > > --- Comment #5 from Martin Uecker <muecker at gwdg dot de> --- > > > It works (and is required to work) for other types, e.g. > > > > > > [[gnu::noinline,gnu::noipa]] > > > int foo(void *p, void *q) > > > { > > > int n = 5; > > > int (*p2)[n] = p; > > > (*p2)[0] = 1; > > > bar(q); > > > return (*p2)[0]; > > > } > > > > > > void bar(void* q) > > > { > > > int n = 5; > > > int (*q2)[n] = q; > > > (*q2)[0] = 2; > > > } > > > > > > One could argue that there is a weaker requirement for having an object > > > 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?) > > > > 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 access. > > I think if you write it as array as above that's already what happens. > > 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 > equivalence classes for structs by ignoring the sizes of all > fields of array type (not just VLA) and also the offsets > 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 > (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). > > > > 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). > > Yes, for pre C23 this is true for all structs even without VLA. > But for C23 this changes. > > 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.
