Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
> On Apr 10, 2024, at 17:56, Joseph Myers wrote:
>
> On Wed, 10 Apr 2024, Qing Zhao wrote:
>
>> Okay, the above is very clear, thanks a lot for the explanation.
>> So, basically, for “counted-by” attribute:
>> **The following is good:
>> struct f {
>> int b;
>> int c;
>> int a[] __attribute__ ((counted_by (b))) };
>> struct f {
>> int b;
>> int c;
>> int a[] __attribute__ ((counted_by (b))) };
>>
>> **The following should error:
>>
>> struct f {
>> int b;
>> int c;
>> int a[] __attribute__ ((counted_by (b))) };
>> struct f {
>> int b;
>> int c;
>> int a[] __attribute__ ((counted_by (c))) }; /* error here */
>>
>> For the same tag in different scopes case:
>>
>> struct f {
>> int b;
>> int c;
>> int a[] __attribute__ ((counted_by (b))) } y0;
>>
>> void test1(void)
>> {
>> struct f {
>> int b;
>> int c;
>> int a[] __attribute__ ((counted_by (c))) } x;
>>
>> y0 = x; /* will report incompatible type error here */
>> }
>>
>> Are the above complete?
>
> Yes, that looks like what should be tested (with the addition of the case
> of same tag, different scopes, same counted_by so compatible).
Okay, thanks for the help.
Qing
>
> --
> Joseph S. Myers
> josmy...@redhat.com
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
> On Apr 11, 2024, at 02:02, Martin Uecker wrote:
>
> Am Mittwoch, dem 10.04.2024 um 19:35 + schrieb Qing Zhao:
>>
>>> On Apr 10, 2024, at 15:05, Martin Uecker wrote:
>>>
>>> Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> On Fri, 29 Mar 2024, Qing Zhao wrote:
>
>> + /* Issue error when there is a counted_by attribute with a different
>> + field as the argument for the same flexible array member field. */
>
> There's another case of this to consider, though I'm not sure where best
> to check for it (Martin might have suggestions) - of course this case
> will
> need testcases as well.
>
> Suppose, as allowed in C23, a structure is defined twice in the same
> scope, but the two definitions of the structure use inconsistent
> counted_by attributes. I'd say that, when the declarations are in the
> same scope (thus required to be consistent), it should be an error for
> the
> two definitions of what is meant to be the same structure to use
> incompatible counted_by attributes (even though the member declarations
> are otherwise the same).
I think the right place could be comp_types_attributes in
attributes.cc. It may be sufficient to set the
affects_type_identify flag.
This should then give a redefinition error as it should do for
"packed".
>>>
>>> Thinking about this a bit more, this will not work here, because
>>> the counted_by attribute is not applied to the struct type but
>>> one of the members.
>>>
>>> So probably there should be a check added directly
>>> to tagged_types_tu_compatible_p
>>
>>
>> There are two cases we will check:
>>
>> A. Both definitions are in the same scope;
>> Then if the 2nd definition has a counted-by attribute different from
>> the 1st definition, the 2nd definition will be given a redefinition error;
>>
>> B. These two definitions are in different scope;
>> When these two definitions are used in a way need to be compatible, an
>> incompatible error need to be issued at that
>> Point;
>>
>>
>> My question is, Will the routine “tagged_types_tu_compatible_p” can handle
>> both A and B?
>
> Yes, changing this function should address both cases if I am
> not missing something.
>
Thanks for the help.
Will study this routine in more details and update the patch.
Qing
> Martin
>
>>
>> Thanks.
>>
>> Qing
>>>
>>> Martin
>>>
>
> In C23 structures defined with the same tag in different scopes are
> compatible given requirements including compatible types for
> corresponding
> elements. It would seem most appropriate to me for such structures with
> incompatible counted_by attributes to be considered *not* compatible
> types
> (but it would be valid to define structures with the same tag, different
> scopes, and elements the same except for counted_by - just not to use
> them
> in any way requiring them to be compatible).
Another option might be to warn about the case when those types
are then used together in a way where they are required to
be compatible. Then comp_types_attributes would have to return 2.
Martin
>
>> +The @code{counted_by} attribute may be attached to the C99 flexible
>> array
>> +member of a structure. It indicates that the number of the elements of
>> the
>> +array is given by the field "@var{count}" in the same structure as the
>
> As noted previously, the "" quotes should be removed there (or replaced
> by
> ``'' quotes).
>
>>>
>>
>
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
Am Mittwoch, dem 10.04.2024 um 19:35 + schrieb Qing Zhao:
>
> > On Apr 10, 2024, at 15:05, Martin Uecker wrote:
> >
> > Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
> > > Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> > > > On Fri, 29 Mar 2024, Qing Zhao wrote:
> > > >
> > > > > + /* Issue error when there is a counted_by attribute with a
> > > > > different
> > > > > + field as the argument for the same flexible array member field.
> > > > > */
> > > >
> > > > There's another case of this to consider, though I'm not sure where
> > > > best
> > > > to check for it (Martin might have suggestions) - of course this case
> > > > will
> > > > need testcases as well.
> > > >
> > > > Suppose, as allowed in C23, a structure is defined twice in the same
> > > > scope, but the two definitions of the structure use inconsistent
> > > > counted_by attributes. I'd say that, when the declarations are in the
> > > > same scope (thus required to be consistent), it should be an error for
> > > > the
> > > > two definitions of what is meant to be the same structure to use
> > > > incompatible counted_by attributes (even though the member declarations
> > > > are otherwise the same).
> > >
> > > I think the right place could be comp_types_attributes in
> > > attributes.cc. It may be sufficient to set the
> > > affects_type_identify flag.
> > >
> > > This should then give a redefinition error as it should do for
> > > "packed".
> >
> > Thinking about this a bit more, this will not work here, because
> > the counted_by attribute is not applied to the struct type but
> > one of the members.
> >
> > So probably there should be a check added directly
> > to tagged_types_tu_compatible_p
>
>
> There are two cases we will check:
>
> A. Both definitions are in the same scope;
> Then if the 2nd definition has a counted-by attribute different from
> the 1st definition, the 2nd definition will be given a redefinition error;
>
> B. These two definitions are in different scope;
> When these two definitions are used in a way need to be compatible, an
> incompatible error need to be issued at that
> Point;
>
>
> My question is, Will the routine “tagged_types_tu_compatible_p” can handle
> both A and B?
Yes, changing this function should address both cases if I am
not missing something.
Martin
>
> Thanks.
>
> Qing
> >
> > Martin
> >
> > >
> > > >
> > > > In C23 structures defined with the same tag in different scopes are
> > > > compatible given requirements including compatible types for
> > > > corresponding
> > > > elements. It would seem most appropriate to me for such structures
> > > > with
> > > > incompatible counted_by attributes to be considered *not* compatible
> > > > types
> > > > (but it would be valid to define structures with the same tag,
> > > > different
> > > > scopes, and elements the same except for counted_by - just not to use
> > > > them
> > > > in any way requiring them to be compatible).
> > >
> > > Another option might be to warn about the case when those types
> > > are then used together in a way where they are required to
> > > be compatible. Then comp_types_attributes would have to return 2.
> > >
> > >
> > > Martin
> > >
> > > >
> > > > > +The @code{counted_by} attribute may be attached to the C99 flexible
> > > > > array
> > > > > +member of a structure. It indicates that the number of the elements
> > > > > of the
> > > > > +array is given by the field "@var{count}" in the same structure as
> > > > > the
> > > >
> > > > As noted previously, the "" quotes should be removed there (or replaced
> > > > by
> > > > ``'' quotes).
> > > >
> > >
> >
>
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
On Wed, 10 Apr 2024, Qing Zhao wrote:
> Okay, the above is very clear, thanks a lot for the explanation.
> So, basically, for “counted-by” attribute:
> **The following is good:
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (b))) };
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (b))) };
>
> **The following should error:
>
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (b))) };
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (c))) }; /* error here */
>
> For the same tag in different scopes case:
>
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (b))) } y0;
>
> void test1(void)
> {
> struct f {
> int b;
> int c;
> int a[] __attribute__ ((counted_by (c))) } x;
>
> y0 = x; /* will report incompatible type error here */
> }
>
> Are the above complete?
Yes, that looks like what should be tested (with the addition of the case
of same tag, different scopes, same counted_by so compatible).
--
Joseph S. Myers
josmy...@redhat.com
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
> On Apr 10, 2024, at 15:05, Martin Uecker wrote:
>
> Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
>> Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
>>> On Fri, 29 Mar 2024, Qing Zhao wrote:
>>>
+ /* Issue error when there is a counted_by attribute with a different
+ field as the argument for the same flexible array member field. */
>>>
>>> There's another case of this to consider, though I'm not sure where best
>>> to check for it (Martin might have suggestions) - of course this case will
>>> need testcases as well.
>>>
>>> Suppose, as allowed in C23, a structure is defined twice in the same
>>> scope, but the two definitions of the structure use inconsistent
>>> counted_by attributes. I'd say that, when the declarations are in the
>>> same scope (thus required to be consistent), it should be an error for the
>>> two definitions of what is meant to be the same structure to use
>>> incompatible counted_by attributes (even though the member declarations
>>> are otherwise the same).
>>
>> I think the right place could be comp_types_attributes in
>> attributes.cc. It may be sufficient to set the
>> affects_type_identify flag.
>>
>> This should then give a redefinition error as it should do for
>> "packed".
>
> Thinking about this a bit more, this will not work here, because
> the counted_by attribute is not applied to the struct type but
> one of the members.
>
> So probably there should be a check added directly
> to tagged_types_tu_compatible_p
There are two cases we will check:
A. Both definitions are in the same scope;
Then if the 2nd definition has a counted-by attribute different from the
1st definition, the 2nd definition will be given a redefinition error;
B. These two definitions are in different scope;
When these two definitions are used in a way need to be compatible, an
incompatible error need to be issued at that
Point;
My question is, Will the routine “tagged_types_tu_compatible_p” can handle both
A and B?
Thanks.
Qing
>
> Martin
>
>>
>>>
>>> In C23 structures defined with the same tag in different scopes are
>>> compatible given requirements including compatible types for corresponding
>>> elements. It would seem most appropriate to me for such structures with
>>> incompatible counted_by attributes to be considered *not* compatible types
>>> (but it would be valid to define structures with the same tag, different
>>> scopes, and elements the same except for counted_by - just not to use them
>>> in any way requiring them to be compatible).
>>
>> Another option might be to warn about the case when those types
>> are then used together in a way where they are required to
>> be compatible. Then comp_types_attributes would have to return 2.
>>
>>
>> Martin
>>
>>>
+The @code{counted_by} attribute may be attached to the C99 flexible array
+member of a structure. It indicates that the number of the elements of
the
+array is given by the field "@var{count}" in the same structure as the
>>>
>>> As noted previously, the "" quotes should be removed there (or replaced by
>>> ``'' quotes).
>>>
>>
>
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
> On Apr 10, 2024, at 14:44, Joseph Myers wrote:
>
> On Wed, 10 Apr 2024, Qing Zhao wrote:
>
>> A stupid question first, the same scope means the same file? (Or same
>> function)
>
> struct X { int a; };
> struct X { int a; };
>
> is an example of the same scope (file scope, in this case). The
> structures must have the same contents (in an appropriate sense) and are
> then considered the same type.
>
> struct X { int a; };
> void f() { struct X { int a; }; }
>
> is not the same scope - but C23 makes the types compatible (not the same).
> It's OK to have incompatible types with the same tag in different scopes
> as well
>
> struct X { int a; };
> void f() { struct X { long b; }; }
>
> but if you use them in a way requiring compatibility, then the contents
> must be compatible
>
> struct X { int a; } v;
> void f() { struct X { int a; } *p = }
Okay, the above is very clear, thanks a lot for the explanation.
So, basically, for “counted-by” attribute:
**The following is good:
struct f {
int b;
int c;
int a[] __attribute__ ((counted_by (b))) };
struct f {
int b;
int c;
int a[] __attribute__ ((counted_by (b))) };
**The following should error:
struct f {
int b;
int c;
int a[] __attribute__ ((counted_by (b))) };
struct f {
int b;
int c;
int a[] __attribute__ ((counted_by (c))) }; /* error here */
For the same tag in different scopes case:
struct f {
int b;
int c;
int a[] __attribute__ ((counted_by (b))) } y0;
void test1(void)
{
struct f {
int b;
int c;
int a[] __attribute__ ((counted_by (c))) } x;
y0 = x; /* will report incompatible type error here */
}
Are the above complete?
>
>> Is there a testing case for this feature in current GCC source tree I can
>> take a look? (and
>> Then I can use it to construct the new testing case for the counted-by
>> attribute).
>
> See gcc.dg/c23-tag-*.c for many tests of different cases involving the tag
> compatibility rules (and gcc.dg/gnu23-tag-* where GNU extensions are
> involved).
Got it. Will take a look on them.
thanks.
Qing
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
Am Mittwoch, dem 10.04.2024 um 20:25 +0200 schrieb Martin Uecker:
> Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> > On Fri, 29 Mar 2024, Qing Zhao wrote:
> >
> > > + /* Issue error when there is a counted_by attribute with a different
> > > + field as the argument for the same flexible array member field. */
> >
> > There's another case of this to consider, though I'm not sure where best
> > to check for it (Martin might have suggestions) - of course this case will
> > need testcases as well.
> >
> > Suppose, as allowed in C23, a structure is defined twice in the same
> > scope, but the two definitions of the structure use inconsistent
> > counted_by attributes. I'd say that, when the declarations are in the
> > same scope (thus required to be consistent), it should be an error for the
> > two definitions of what is meant to be the same structure to use
> > incompatible counted_by attributes (even though the member declarations
> > are otherwise the same).
>
> I think the right place could be comp_types_attributes in
> attributes.cc. It may be sufficient to set the
> affects_type_identify flag.
>
> This should then give a redefinition error as it should do for
> "packed".
Thinking about this a bit more, this will not work here, because
the counted_by attribute is not applied to the struct type but
one of the members.
So probably there should be a check added directly
to tagged_types_tu_compatible_p
Martin
>
> >
> > In C23 structures defined with the same tag in different scopes are
> > compatible given requirements including compatible types for corresponding
> > elements. It would seem most appropriate to me for such structures with
> > incompatible counted_by attributes to be considered *not* compatible types
> > (but it would be valid to define structures with the same tag, different
> > scopes, and elements the same except for counted_by - just not to use them
> > in any way requiring them to be compatible).
>
> Another option might be to warn about the case when those types
> are then used together in a way where they are required to
> be compatible. Then comp_types_attributes would have to return 2.
>
>
> Martin
>
> >
> > > +The @code{counted_by} attribute may be attached to the C99 flexible array
> > > +member of a structure. It indicates that the number of the elements of
> > > the
> > > +array is given by the field "@var{count}" in the same structure as the
> >
> > As noted previously, the "" quotes should be removed there (or replaced by
> > ``'' quotes).
> >
>
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
On Wed, 10 Apr 2024, Qing Zhao wrote:
> A stupid question first, the same scope means the same file? (Or same
> function)
struct X { int a; };
struct X { int a; };
is an example of the same scope (file scope, in this case). The
structures must have the same contents (in an appropriate sense) and are
then considered the same type.
struct X { int a; };
void f() { struct X { int a; }; }
is not the same scope - but C23 makes the types compatible (not the same).
It's OK to have incompatible types with the same tag in different scopes
as well
struct X { int a; };
void f() { struct X { long b; }; }
but if you use them in a way requiring compatibility, then the contents
must be compatible
struct X { int a; } v;
void f() { struct X { int a; } *p = }
> Is there a testing case for this feature in current GCC source tree I can
> take a look? (and
> Then I can use it to construct the new testing case for the counted-by
> attribute).
See gcc.dg/c23-tag-*.c for many tests of different cases involving the tag
compatibility rules (and gcc.dg/gnu23-tag-* where GNU extensions are
involved).
--
Joseph S. Myers
josmy...@redhat.com
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
Am Mittwoch, dem 10.04.2024 um 17:35 + schrieb Joseph Myers:
> On Fri, 29 Mar 2024, Qing Zhao wrote:
>
> > + /* Issue error when there is a counted_by attribute with a different
> > + field as the argument for the same flexible array member field. */
>
> There's another case of this to consider, though I'm not sure where best
> to check for it (Martin might have suggestions) - of course this case will
> need testcases as well.
>
> Suppose, as allowed in C23, a structure is defined twice in the same
> scope, but the two definitions of the structure use inconsistent
> counted_by attributes. I'd say that, when the declarations are in the
> same scope (thus required to be consistent), it should be an error for the
> two definitions of what is meant to be the same structure to use
> incompatible counted_by attributes (even though the member declarations
> are otherwise the same).
I think the right place could be comp_types_attributes in
attributes.cc. It may be sufficient to set the
affects_type_identify flag.
This should then give a redefinition error as it should do for
"packed".
>
> In C23 structures defined with the same tag in different scopes are
> compatible given requirements including compatible types for corresponding
> elements. It would seem most appropriate to me for such structures with
> incompatible counted_by attributes to be considered *not* compatible types
> (but it would be valid to define structures with the same tag, different
> scopes, and elements the same except for counted_by - just not to use them
> in any way requiring them to be compatible).
Another option might be to warn about the case when those types
are then used together in a way where they are required to
be compatible. Then comp_types_attributes would have to return 2.
Martin
>
> > +The @code{counted_by} attribute may be attached to the C99 flexible array
> > +member of a structure. It indicates that the number of the elements of the
> > +array is given by the field "@var{count}" in the same structure as the
>
> As noted previously, the "" quotes should be removed there (or replaced by
> ``'' quotes).
>
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
Thanks for the comments.
> On Apr 10, 2024, at 13:35, Joseph Myers wrote:
>
> On Fri, 29 Mar 2024, Qing Zhao wrote:
>
>> + /* Issue error when there is a counted_by attribute with a different
>> + field as the argument for the same flexible array member field. */
>
> There's another case of this to consider, though I'm not sure where best
> to check for it (Martin might have suggestions) - of course this case will
> need testcases as well.
Looks like this additional case relates to the new C23 feature, where is the
documentation on this new feature, I need to study a little bit on this, thanks.
>
> Suppose, as allowed in C23, a structure is defined twice in the same
> scope,
A stupid question first, the same scope means the same file? (Or same function)
Is there a testing case for this feature in current GCC source tree I can take
a look? (and
Then I can use it to construct the new testing case for the counted-by
attribute).
> but the two definitions of the structure use inconsistent
> counted_by attributes.
Where in the current C FE to handle the same structure is defined twice in the
same scope? Which routine
In the C FE?
> I'd say that, when the declarations are in the
> same scope (thus required to be consistent), it should be an error for the
> two definitions of what is meant to be the same structure to use
> incompatible counted_by attributes (even though the member declarations
> are otherwise the same).
Agreed. Wil add such checking.
>
> In C23 structures defined with the same tag in different scopes are
> compatible given requirements including compatible types for corresponding
> elements.
Again, which routine in the C FE handle such case? I’d like to take a look at
the current
Handling and how to update it for the counted-by attribute.
> It would seem most appropriate to me for such structures with
> incompatible counted_by attributes to be considered *not* compatible types
Is there a utility routine for checking “compatible type”?
> (but it would be valid to define structures with the same tag, different
> scopes, and elements the same except for counted_by - just not to use them
> in any way requiring them to be compatible).
Updating that routine (checking compatible type) with the new “counted-by”
attribute
Might be enough for this purpose, I guess.
>
>> +The @code{counted_by} attribute may be attached to the C99 flexible array
>> +member of a structure. It indicates that the number of the elements of the
>> +array is given by the field "@var{count}" in the same structure as the
>
> As noted previously, the "" quotes should be removed there (or replaced by
> ``'' quotes).
Okay, will update this.
thanks.
Qing
>
> --
> Joseph S. Myers
> josmy...@redhat.com
>
Re: [PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
On Fri, 29 Mar 2024, Qing Zhao wrote:
> + /* Issue error when there is a counted_by attribute with a different
> + field as the argument for the same flexible array member field. */
There's another case of this to consider, though I'm not sure where best
to check for it (Martin might have suggestions) - of course this case will
need testcases as well.
Suppose, as allowed in C23, a structure is defined twice in the same
scope, but the two definitions of the structure use inconsistent
counted_by attributes. I'd say that, when the declarations are in the
same scope (thus required to be consistent), it should be an error for the
two definitions of what is meant to be the same structure to use
incompatible counted_by attributes (even though the member declarations
are otherwise the same).
In C23 structures defined with the same tag in different scopes are
compatible given requirements including compatible types for corresponding
elements. It would seem most appropriate to me for such structures with
incompatible counted_by attributes to be considered *not* compatible types
(but it would be valid to define structures with the same tag, different
scopes, and elements the same except for counted_by - just not to use them
in any way requiring them to be compatible).
> +The @code{counted_by} attribute may be attached to the C99 flexible array
> +member of a structure. It indicates that the number of the elements of the
> +array is given by the field "@var{count}" in the same structure as the
As noted previously, the "" quotes should be removed there (or replaced by
``'' quotes).
--
Joseph S. Myers
josmy...@redhat.com
[PATCH v8 1/5] Provide counted_by attribute to flexible array member field (PR108896)
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field "COUNT" in the
same structure as the flexible array member.
GCC may use this information to improve detection of object size
information
for such structures and provide better results in compile-time diagnostics
and runtime features like the array bound sanitizer and
the '__builtin_dynamic_object_size'.
For instance, the following code:
struct P {
size_t count;
char other;
char array[] __attribute__ ((counted_by (count)));
} *p;
specifies that the 'array' is a flexible array member whose number
of elements is given by the field 'count' in the same structure.
The field that represents the number of the elements should have an
integer type. Otherwise, the compiler reports an error and
ignores the attribute.
When the field that represents the number of the elements is assigned a
negative integer value, the compiler treats the value as zero.
An explicit 'counted_by' annotation defines a relationship between
two objects, 'p->array' and 'p->count', and there are the following
requirementthat on the relationship between this pair:
* 'p->count' must be initialized before the first reference to
'p->array';
* 'p->array' has _at least_ 'p->count' number of elements
available all the time. This relationship must hold even
after any of these related objects are updated during the
program.
It's the user's responsibility to make sure the above requirements
to be kept all the time. Otherwise the compiler reports
warnings, at the same time, the results of the array bound
sanitizer and the '__builtin_dynamic_object_size' is undefined.
One important feature of the attribute is, a reference to the
flexible array member field uses the latest value assigned to
the field that represents the number of the elements before that
reference. For example,
p->count = val1;
p->array[20] = 0; // ref1 to p->array
p->count = val2;
p->array[30] = 0; // ref2 to p->array
in the above, 'ref1' uses 'val1' as the number of the elements
in 'p->array', and 'ref2' uses 'val2' as the number of elements
in 'p->array'.
gcc/c-family/ChangeLog:
PR C/108896
* c-attribs.cc (handle_counted_by_attribute): New function.
(attribute_takes_identifier_p): Add counted_by attribute to the list.
* c-common.cc (c_flexible_array_member_type_p): ...To this.
* c-common.h (c_flexible_array_member_type_p): New prototype.
gcc/c/ChangeLog:
PR C/108896
* c-decl.cc (flexible_array_member_type_p): Renamed and moved to...
(add_flexible_array_elts_to_size): Use renamed function.
(is_flexible_array_member_p): Use renamed function.
(verify_counted_by_attribute): New function.
(finish_struct): Use renamed function and verify counted_by
attribute.
* c-tree.h (lookup_field): New prototype.
* c-typeck.cc (lookup_field): Expose as extern function.
gcc/ChangeLog:
PR C/108896
* doc/extend.texi: Document attribute counted_by.
gcc/testsuite/ChangeLog:
PR C/108896
* gcc.dg/flex-array-counted-by.c: New test.
* gcc.dg/flex-array-counted-by-7.c: New test.
---
gcc/c-family/c-attribs.cc | 68 +++-
gcc/c-family/c-common.cc | 13
gcc/c-family/c-common.h | 1 +
gcc/c/c-decl.cc | 78 +++
gcc/c/c-tree.h| 1 +
gcc/c/c-typeck.cc | 3 +-
gcc/doc/extend.texi | 68
.../gcc.dg/flex-array-counted-by-7.c | 8 ++
gcc/testsuite/gcc.dg/flex-array-counted-by.c | 62 +++
9 files changed, 282 insertions(+), 20 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by-7.c
create mode 100644 gcc/testsuite/gcc.dg/flex-array-counted-by.c
diff --git a/gcc/c-family/c-attribs.cc b/gcc/c-family/c-attribs.cc
index 40a0cf90295d..39e5824ee7a5 100644
--- a/gcc/c-family/c-attribs.cc
+++ b/gcc/c-family/c-attribs.cc
@@ -105,6 +105,8 @@ static tree handle_warn_if_not_aligned_attribute (tree *,
tree, tree,
int, bool *);
static tree handle_strict_flex_array_attribute (tree *, tree, tree,
int, bool *);
+static tree handle_counted_by_attribute (tree *, tree, tree,
+ int, bool *);
static tree handle_weak_attribute (tree *, tree, tree, int, bool *) ;
