Am Dienstag, dem 22.10.2024 um 16:15 +0000 schrieb Qing Zhao:
>
> > On Oct 21, 2024, at 17:29, Martin Uecker <[email protected]> wrote:
> >
> > Am Montag, dem 21.10.2024 um 21:09 +0000 schrieb Joseph Myers:
> > > On Sat, 19 Oct 2024, Martin Uecker wrote:
> > >
> > > > Hi Quin and Joseph,
(thanks for sending the links, I totally forgot about the discussion).
> > > >
> > > > I saw that there is now new code in tu_tagged_types_compatible
> > > > which makes structure type incompatible depending on whether
> > > > there is ac counted_by attribute. Is this what we want? I think a
> > > > warning might make more sense as this types are fundamentally
> > > > still compatible.
> > >
> > > If the types were compatible you'd need a composite type. If the
> > > composite type has the flexible array counted by both the integer
> > > elements
> > > named with counted_by attributes (one in one of the types and one in the
> > > other), that really doesn't make sense to me.
> >
> > I doesn't really make sense when they are inconsistent.
> > Still, we could just warn and pick one of the attributes
> > when forming the composite type.
>
> If both are defined locally, such inconsistencies should be very easily fixed
> in the source code level.
> And I think that such inconsistencies should be fixed in the source code.
> Therefore, reporting error
> makes more sense to me.
I agree, and error makes sense. What worries me a little bit
is tying this to a semantic change in type compatibility.
typedef struct foo { int n; int m;
[[gnu::counted_by(n)]] char buf[]; } aaa_t;
void foo()
{
struct foo { int n; int m;
[[gnu::counted_by(m)]] char buf[]; } *b;
... = _Generic(b, aaa_t*: 1, default: 0);
}
would go into the default branch for compilers supporting
the attribute but go into the first branch for others. Also
it affects ailasing rules.
But maybe this is not a problem.
> >
> > But I was thinking about the case where you have a type with
> > a counted_by attribute and one without. Using them together
> > seems useful, e.g. to add a counted_by in your local version
> > of a type which needs to be compatible to some API.
>
> For API compatibility purpose, yes, I agree here.
> A stupid question here: if one is defined locally, the other one
> is NOT defined locally, can such inconsistency be caught by the
> same compilation (is this the LTO compilation?)
If there is separate compilation this is not catched. LTO
has a much coarser notion of types and would not notice
either (I believe).
> Suppose we can catch such inconsistency in the same compilation,
> which version we should keep? I guess that we should keep the
> version without the counted_by attribute?
>
I would keep the one with the attribute, because this is the
one which has more information.
Martin
