Am Dienstag, dem 28.11.2023 um 10:47 +0000 schrieb Richard Biener:
> On Tue, 28 Nov 2023, Joseph Myers wrote:
>
> > On Sun, 26 Nov 2023, Martin Uecker wrote:
> >
>
> > > > I also think more rationale is needed for ignoring sizes like this. Is
> > > > it
> > > > intended for e.g. making structs with flexible array members
> > > > alias-compatible with similar structs with a fixed-size array?
> > >
> > > The main reason are pointers to arrays:
> > >
> > > struct foo { int (*x)[]; }
> > > struct foo { int (*x)[2]; };
> > > struct foo { int (*x)[1]; };
> >
> > Thanks for the explanation.
> >
> > I guess the cases involving flexible array members actually show up a bug
> > in the standard rather than any kind of issue with this patch - the
> > standard allows one structure ending with a flexible array member, and
> > another ending with a fixed-size array, to be compatible (and in different
> > translation units allowed that even before C23), but there is also clear
> > text in the standard showing it's not intended to require the layout to be
> > consistent (the fixed-size and flexible arrays might have different
> > offsets), and what you'd actually get with an assignment or conditional
> > expression mixing such structures certainly isn't clearly specified.
> > Maybe the right resolution for that issue with the standard would be to
> > make that particular case incompatible, but it would need to be raised as
> > an issue after C23 is out.
>
> I think from a middle-end perspective it's desirable that accessing
> either of the foo with size 2 and 1 through a pointer of the type
> of the foo with unknown size is permissible from a TBAA view. But
> it's not clear to me that accessing the foo with array size 2 via
> an lvalue of the type of foo with array size 1 is required to be
> supported (from a TBAA view).
This is the same from the C language side. In principle, accesses
to an object with effective type foo [2] using an lvalue of type
foo [1] or vice versa are undefined behavior.
So a model based on equivalence classes loses some information.
Martin
