Am Mittwoch, dem 23.10.2024 um 14:32 +0000 schrieb Qing Zhao:
>
> > On Oct 22, 2024, at 15:16, Martin Uecker <uec...@tugraz.at> wrote:
> >
> > > > >
> > > >
> > > > 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.
>
> So, they are in separate compilations? Then the compiler is not able to catch
> such
> inconsistency during compilation time.
I am not entirely sure what you mean by this.
These are two different types in different scopes, so they
are allowed to be different.
But _Generic then tests whether they are compatible and
takes the attribute into account for GCC. But for
earlier GCC or other compilers that do not support the
attribute the result would be different.
So maybe instead of changing the return value of comptypes,
we simply set different_types_p (which would prevent
redeclaration in the same scope) and also set another flag
similar to enum_and_int_p (e.g. inconsistent_counted_by_p)
and emit an error in the callers at some appropriate places.
> >
> > But maybe this is not a problem.
> This does look like an issue to me…
> Not sure how to resolve such issue at this moment.
>
> Or, only when the “counted_by” information is included into the TYPE, such
> issue can be resolved?
>
> >
> > > >
> > > > 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).
>
> Okay. Then such inconsistency will not be caught during compilation time.
Yeah, but here we will miss many other inconsistencies too...
>
> >
> > > 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.
> Make sense to me
>
Martin
> .
>
> Thanks.
> Qing
> >
> >
> > Martin
>
>
--
Univ.-Prof. Dr. rer. nat. Martin Uecker
Graz University of Technology
Institute of Biomedical Imaging
