gcc-13/changes.html: Mention -fstrict-flex-arrays and its impact
Checks
Commit Message
Hi,
This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
Let me know if you have any comment or suggestions.
Thanks.
Qing.
=======================================
From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
From: Qing Zhao <qing.zhao@oracle.com>
Date: Tue, 20 Dec 2022 16:13:04 +0000
Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
---
htdocs/gcc-13/changes.html | 15 +++++++++++++++
1 file changed, 15 insertions(+)
Comments
On Tue, 20 Dec 2022, Qing Zhao wrote:
> Hi,
>
> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
>
> Let me know if you have any comment or suggestions.
Some copy editing below
> Thanks.
>
> Qing.
>
> =======================================
> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
> From: Qing Zhao <qing.zhao@oracle.com>
> Date: Tue, 20 Dec 2022 16:13:04 +0000
> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
>
> ---
> htdocs/gcc-13/changes.html | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> index 689178f9..47b3d40f 100644
> --- a/htdocs/gcc-13/changes.html
> +++ b/htdocs/gcc-13/changes.html
> @@ -39,6 +39,10 @@ a work-in-progress.</p>
> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
> and the option is ignored right now.</li>
> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
> + accesses to trailing struct members of one-element array type anymore. Please
> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
> + trailing arrays of structures as flexible array members. </li>
"Instead it diagnoses accesses to trailing arrays according to
<code>-fstrict-flex-arrays</code>."
> </ul>
>
>
> @@ -409,6 +413,17 @@ a work-in-progress.</p>
> <h2>Other significant improvements</h2>
>
> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
> +
> +<ul>
> + <li>GCC can now control when to treat the trailing array of a structure as a
> + flexible array member for the purpose of accessing the elements of such
> + an array. By default, all trailing arrays of structures are treated as
all trailing arrays in aggregates are treated
> + flexible array members. Use the new command-line option
> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
> + array of a structure as a flexible array member at different levels.
<code>-fstrict-flex-arrays</code> to control which trailing array
members are streated as flexible arrays.
I've also just now noticed that there's now a flag_strict_flex_arrays
check in the middle-end (in array bound diagnostics) but this option
isn't streamed or handled with LTO. I think you want to replace that
with the appropriate DECL_NOT_FLEXARRAY check. We might also want
to see how inlining accesses from TUs with different -fstrict-flex-arrays
setting behaves when accessing the same structure (and whether we might
want to issue an ODR style diagnostic there).
Thanks,
Richard.
Hi, Richard,
Thanks a lot for your comments.
> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote:
>
> On Tue, 20 Dec 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
>>
>> Let me know if you have any comment or suggestions.
>
> Some copy editing below
>
>> Thanks.
>>
>> Qing.
>>
>> =======================================
>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
>> From: Qing Zhao <qing.zhao@oracle.com>
>> Date: Tue, 20 Dec 2022 16:13:04 +0000
>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
>>
>> ---
>> htdocs/gcc-13/changes.html | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
>> index 689178f9..47b3d40f 100644
>> --- a/htdocs/gcc-13/changes.html
>> +++ b/htdocs/gcc-13/changes.html
>> @@ -39,6 +39,10 @@ a work-in-progress.</p>
>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
>> and the option is ignored right now.</li>
>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
>> + accesses to trailing struct members of one-element array type anymore. Please
>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
>> + trailing arrays of structures as flexible array members. </li>
>
> "Instead it diagnoses accesses to trailing arrays according to
> <code>-fstrict-flex-arrays</code>."
Okay.
>
>> </ul>
>>
>>
>> @@ -409,6 +413,17 @@ a work-in-progress.</p>
>> <h2>Other significant improvements</h2>
>>
>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
>> +
>> +<ul>
>> + <li>GCC can now control when to treat the trailing array of a structure as a
>> + flexible array member for the purpose of accessing the elements of such
>> + an array. By default, all trailing arrays of structures are treated as
>
> all trailing arrays in aggregates are treated
Okay.
>
>> + flexible array members. Use the new command-line option
>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
>> + array of a structure as a flexible array member at different levels.
>
> <code>-fstrict-flex-arrays</code> to control which trailing array
> members are streated as flexible arrays.
Okay.
>
> I've also just now noticed that there's now a flag_strict_flex_arrays
> check in the middle-end (in array bound diagnostics) but this option
> isn't streamed or handled with LTO. I think you want to replace that
> with the appropriate DECL_NOT_FLEXARRAY check.
We need to know the level value of the strict_flex_arrays on the struct field to issue proper warnings at different levels.
DECL_NOT_FLEXARRAY does not include such info.
So, what should I do? Streaming the flag_strict_flex_arrays with LTO?
> We might also want
> to see how inlining accesses from TUs with different -fstrict-flex-arrays
> setting behaves when accessing the same structure (and whether we might
> want to issue an ODR style diagnostic there).
Yes, good point, I will check on this part.
BTW, a stupid question: what does ODR mean?
thanks.
Qing
>
> Thanks,
> Richard.
On Wed, 21 Dec 2022, Qing Zhao wrote:
> Hi, Richard,
>
> Thanks a lot for your comments.
>
> > On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote:
> >
> > On Tue, 20 Dec 2022, Qing Zhao wrote:
> >
> >> Hi,
> >>
> >> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
> >>
> >> Let me know if you have any comment or suggestions.
> >
> > Some copy editing below
> >
> >> Thanks.
> >>
> >> Qing.
> >>
> >> =======================================
> >> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
> >> From: Qing Zhao <qing.zhao@oracle.com>
> >> Date: Tue, 20 Dec 2022 16:13:04 +0000
> >> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
> >>
> >> ---
> >> htdocs/gcc-13/changes.html | 15 +++++++++++++++
> >> 1 file changed, 15 insertions(+)
> >>
> >> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> >> index 689178f9..47b3d40f 100644
> >> --- a/htdocs/gcc-13/changes.html
> >> +++ b/htdocs/gcc-13/changes.html
> >> @@ -39,6 +39,10 @@ a work-in-progress.</p>
> >> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
> >> and the option is ignored right now.</li>
> >> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
> >> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
> >> + accesses to trailing struct members of one-element array type anymore. Please
> >> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
> >> + trailing arrays of structures as flexible array members. </li>
> >
> > "Instead it diagnoses accesses to trailing arrays according to
> > <code>-fstrict-flex-arrays</code>."
>
> Okay.
> >
> >> </ul>
> >>
> >>
> >> @@ -409,6 +413,17 @@ a work-in-progress.</p>
> >> <h2>Other significant improvements</h2>
> >>
> >> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
> >> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
> >> +
> >> +<ul>
> >> + <li>GCC can now control when to treat the trailing array of a structure as a
> >> + flexible array member for the purpose of accessing the elements of such
> >> + an array. By default, all trailing arrays of structures are treated as
> >
> > all trailing arrays in aggregates are treated
> Okay.
> >
> >> + flexible array members. Use the new command-line option
> >> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
> >> + array of a structure as a flexible array member at different levels.
> >
> > <code>-fstrict-flex-arrays</code> to control which trailing array
> > members are streated as flexible arrays.
>
> Okay.
>
> >
> > I've also just now noticed that there's now a flag_strict_flex_arrays
> > check in the middle-end (in array bound diagnostics) but this option
> > isn't streamed or handled with LTO. I think you want to replace that
> > with the appropriate DECL_NOT_FLEXARRAY check.
>
> We need to know the level value of the strict_flex_arrays on the struct
> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY
> does not include such info. So, what should I do? Streaming the
> flag_strict_flex_arrays with LTO?
But you do
if (compref)
{
/* Try to determine special array member type for this
COMPONENT_REF. */
sam = component_ref_sam_type (arg);
/* Get the level of strict_flex_array for this array field. */
tree afield_decl = TREE_OPERAND (arg, 1);
strict_flex_array_level = strict_flex_array_level_of (afield_decl);
I see that function doesn't look at DECL_NOT_FLEXARRAY but just
checks attributes (those are streamed in LTO).
OK, so I suppose the diagnostic itself would become just less precise
as in "trailing array %qT should not be used as a flexible array member"
without the "for level N and above" part of the diagnostic?
> > We might also want
> > to see how inlining accesses from TUs with different -fstrict-flex-arrays
> > setting behaves when accessing the same structure (and whether we might
> > want to issue an ODR style diagnostic there).
This mixing also means streaming -fstrict-flex-arrays won't be of much
help in general.
> Yes, good point, I will check on this part.
>
> BTW, a stupid question: what does ODR mean?
It's the One-Definition-Rule (of C++). Basically we'd diagnose
same struct declarations with different -fstrict-flex-arrays setting.
I see we miss comparing DECL_NOT_FLEXARRAY for tree merging, I'm
testing a patch to fix that now.
Richard.
> thanks.
>
> Qing
> >
> > Thanks,
> > Richard.
>
>
> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote:
>
> On Wed, 21 Dec 2022, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> Thanks a lot for your comments.
>>
>>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote:
>>>
>>> On Tue, 20 Dec 2022, Qing Zhao wrote:
>>>
>>>> Hi,
>>>>
>>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
>>>>
>>>> Let me know if you have any comment or suggestions.
>>>
>>> Some copy editing below
>>>
>>>> Thanks.
>>>>
>>>> Qing.
>>>>
>>>> =======================================
>>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
>>>> From: Qing Zhao <qing.zhao@oracle.com>
>>>> Date: Tue, 20 Dec 2022 16:13:04 +0000
>>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
>>>>
>>>> ---
>>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++
>>>> 1 file changed, 15 insertions(+)
>>>>
>>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
>>>> index 689178f9..47b3d40f 100644
>>>> --- a/htdocs/gcc-13/changes.html
>>>> +++ b/htdocs/gcc-13/changes.html
>>>> @@ -39,6 +39,10 @@ a work-in-progress.</p>
>>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
>>>> and the option is ignored right now.</li>
>>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
>>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
>>>> + accesses to trailing struct members of one-element array type anymore. Please
>>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
>>>> + trailing arrays of structures as flexible array members. </li>
>>>
>>> "Instead it diagnoses accesses to trailing arrays according to
>>> <code>-fstrict-flex-arrays</code>."
>>
>> Okay.
>>>
>>>> </ul>
>>>>
>>>>
>>>> @@ -409,6 +413,17 @@ a work-in-progress.</p>
>>>> <h2>Other significant improvements</h2>
>>>>
>>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
>>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
>>>> +
>>>> +<ul>
>>>> + <li>GCC can now control when to treat the trailing array of a structure as a
>>>> + flexible array member for the purpose of accessing the elements of such
>>>> + an array. By default, all trailing arrays of structures are treated as
>>>
>>> all trailing arrays in aggregates are treated
>> Okay.
>>>
>>>> + flexible array members. Use the new command-line option
>>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
>>>> + array of a structure as a flexible array member at different levels.
>>>
>>> <code>-fstrict-flex-arrays</code> to control which trailing array
>>> members are streated as flexible arrays.
>>
>> Okay.
>>
>>>
>>> I've also just now noticed that there's now a flag_strict_flex_arrays
>>> check in the middle-end (in array bound diagnostics) but this option
>>> isn't streamed or handled with LTO. I think you want to replace that
>>> with the appropriate DECL_NOT_FLEXARRAY check.
>>
>> We need to know the level value of the strict_flex_arrays on the struct
>> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY
>> does not include such info. So, what should I do? Streaming the
>> flag_strict_flex_arrays with LTO?
>
> But you do
>
> if (compref)
> {
> /* Try to determine special array member type for this
> COMPONENT_REF. */
> sam = component_ref_sam_type (arg);
> /* Get the level of strict_flex_array for this array field. */
> tree afield_decl = TREE_OPERAND (arg, 1);
> strict_flex_array_level = strict_flex_array_level_of (afield_decl);
>
> I see that function doesn't look at DECL_NOT_FLEXARRAY but just
> checks attributes (those are streamed in LTO).
Yes, checked both flag_strict_flex_arrays and attributes.
There are two places in middle end calling “strict_flex_array_level_of” function,
one inside “array_bounds_checker::check_array_ref”, another one inside “component_ref_size”.
Shall we check DECL_NOT_FLEXARRAY field instead of calling “strict_flex_array_level_of” in both places?
>
> OK, so I suppose the diagnostic itself would become just less precise
> as in "trailing array %qT should not be used as a flexible array member"
> without the "for level N and above" part of the diagnostic?
Yes, that might be the major impact.
If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter?
>
>>> We might also want
>>> to see how inlining accesses from TUs with different -fstrict-flex-arrays
>>> setting behaves when accessing the same structure (and whether we might
>>> want to issue an ODR style diagnostic there).
>
> This mixing also means streaming -fstrict-flex-arrays won't be of much
> help in general.
Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it?
>
>> Yes, good point, I will check on this part.
>>
>> BTW, a stupid question: what does ODR mean?
>
> It's the One-Definition-Rule (of C++). Basically we'd diagnose
> same struct declarations with different -fstrict-flex-arrays setting.
> I see we miss comparing DECL_NOT_FLEXARRAY for tree merging, I'm
> testing a patch to fix that now.
Okay, thanks a lot for the help.
Qing
>
> Richard.
>
>> thanks.
>>
>> Qing
>>>
>>> Thanks,
>>> Richard.
>>
>>
>
> --
> Richard Biener <rguenther@suse.de>
> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
> Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
> HRB 36809 (AG Nuernberg)
On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>
> > On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote:
> >
> > On Wed, 21 Dec 2022, Qing Zhao wrote:
> >
> >> Hi, Richard,
> >>
> >> Thanks a lot for your comments.
> >>
> >>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote:
> >>>
> >>> On Tue, 20 Dec 2022, Qing Zhao wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
> >>>>
> >>>> Let me know if you have any comment or suggestions.
> >>>
> >>> Some copy editing below
> >>>
> >>>> Thanks.
> >>>>
> >>>> Qing.
> >>>>
> >>>> =======================================
> >>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
> >>>> From: Qing Zhao <qing.zhao@oracle.com>
> >>>> Date: Tue, 20 Dec 2022 16:13:04 +0000
> >>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
> >>>>
> >>>> ---
> >>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++
> >>>> 1 file changed, 15 insertions(+)
> >>>>
> >>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> >>>> index 689178f9..47b3d40f 100644
> >>>> --- a/htdocs/gcc-13/changes.html
> >>>> +++ b/htdocs/gcc-13/changes.html
> >>>> @@ -39,6 +39,10 @@ a work-in-progress.</p>
> >>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
> >>>> and the option is ignored right now.</li>
> >>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
> >>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
> >>>> + accesses to trailing struct members of one-element array type anymore. Please
> >>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
> >>>> + trailing arrays of structures as flexible array members. </li>
> >>>
> >>> "Instead it diagnoses accesses to trailing arrays according to
> >>> <code>-fstrict-flex-arrays</code>."
> >>
> >> Okay.
> >>>
> >>>> </ul>
> >>>>
> >>>>
> >>>> @@ -409,6 +413,17 @@ a work-in-progress.</p>
> >>>> <h2>Other significant improvements</h2>
> >>>>
> >>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
> >>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
> >>>> +
> >>>> +<ul>
> >>>> + <li>GCC can now control when to treat the trailing array of a structure as a
> >>>> + flexible array member for the purpose of accessing the elements of such
> >>>> + an array. By default, all trailing arrays of structures are treated as
> >>>
> >>> all trailing arrays in aggregates are treated
> >> Okay.
> >>>
> >>>> + flexible array members. Use the new command-line option
> >>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
> >>>> + array of a structure as a flexible array member at different levels.
> >>>
> >>> <code>-fstrict-flex-arrays</code> to control which trailing array
> >>> members are streated as flexible arrays.
> >>
> >> Okay.
> >>
> >>>
> >>> I've also just now noticed that there's now a flag_strict_flex_arrays
> >>> check in the middle-end (in array bound diagnostics) but this option
> >>> isn't streamed or handled with LTO. I think you want to replace that
> >>> with the appropriate DECL_NOT_FLEXARRAY check.
> >>
> >> We need to know the level value of the strict_flex_arrays on the struct
> >> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY
> >> does not include such info. So, what should I do? Streaming the
> >> flag_strict_flex_arrays with LTO?
> >
> > But you do
> >
> > if (compref)
> > {
> > /* Try to determine special array member type for this
> > COMPONENT_REF. */
> > sam = component_ref_sam_type (arg);
> > /* Get the level of strict_flex_array for this array field. */
> > tree afield_decl = TREE_OPERAND (arg, 1);
> > strict_flex_array_level = strict_flex_array_level_of (afield_decl);
> >
> > I see that function doesn't look at DECL_NOT_FLEXARRAY but just
> > checks attributes (those are streamed in LTO).
>
> Yes, checked both flag_strict_flex_arrays and attributes.
>
> There are two places in middle end calling ?strict_flex_array_level_of? function,
> one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?.
> Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places?
I wonder if that function should check DECL_NOT_FLEXARRAY?
> >
> > OK, so I suppose the diagnostic itself would become just less precise
> > as in "trailing array %qT should not be used as a flexible array member"
> > without the "for level N and above" part of the diagnostic?
>
> Yes, that might be the major impact.
>
> If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter?
I think the main information is preserved in diagnosing the flex vs.
non-flex array assumption.
> >
> >>> We might also want
> >>> to see how inlining accesses from TUs with different -fstrict-flex-arrays
> >>> setting behaves when accessing the same structure (and whether we might
> >>> want to issue an ODR style diagnostic there).
> >
> > This mixing also means streaming -fstrict-flex-arrays won't be of much
> > help in general.
>
> Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it?
I think in similar situations we try to DWIM, but in some cases it will
result in "garbage" behavior. I don't think there's anything we can
do here besides trying to diagnose such mismatches with -flto at the WPA
stage.
Richard.
> On Jan 9, 2023, at 2:11 AM, Richard Biener <rguenther@suse.de> wrote:
>
> On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>>
>>
>>> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote:
>>>
>>> On Wed, 21 Dec 2022, Qing Zhao wrote:
>>>
>>>> Hi, Richard,
>>>>
>>>> Thanks a lot for your comments.
>>>>
>>>>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote:
>>>>>
>>>>> On Tue, 20 Dec 2022, Qing Zhao wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
>>>>>>
>>>>>> Let me know if you have any comment or suggestions.
>>>>>
>>>>> Some copy editing below
>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Qing.
>>>>>>
>>>>>> =======================================
>>>>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
>>>>>> From: Qing Zhao <qing.zhao@oracle.com>
>>>>>> Date: Tue, 20 Dec 2022 16:13:04 +0000
>>>>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
>>>>>>
>>>>>> ---
>>>>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++
>>>>>> 1 file changed, 15 insertions(+)
>>>>>>
>>>>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
>>>>>> index 689178f9..47b3d40f 100644
>>>>>> --- a/htdocs/gcc-13/changes.html
>>>>>> +++ b/htdocs/gcc-13/changes.html
>>>>>> @@ -39,6 +39,10 @@ a work-in-progress.</p>
>>>>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
>>>>>> and the option is ignored right now.</li>
>>>>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
>>>>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
>>>>>> + accesses to trailing struct members of one-element array type anymore. Please
>>>>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
>>>>>> + trailing arrays of structures as flexible array members. </li>
>>>>>
>>>>> "Instead it diagnoses accesses to trailing arrays according to
>>>>> <code>-fstrict-flex-arrays</code>."
>>>>
>>>> Okay.
>>>>>
>>>>>> </ul>
>>>>>>
>>>>>>
>>>>>> @@ -409,6 +413,17 @@ a work-in-progress.</p>
>>>>>> <h2>Other significant improvements</h2>
>>>>>>
>>>>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
>>>>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
>>>>>> +
>>>>>> +<ul>
>>>>>> + <li>GCC can now control when to treat the trailing array of a structure as a
>>>>>> + flexible array member for the purpose of accessing the elements of such
>>>>>> + an array. By default, all trailing arrays of structures are treated as
>>>>>
>>>>> all trailing arrays in aggregates are treated
>>>> Okay.
>>>>>
>>>>>> + flexible array members. Use the new command-line option
>>>>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
>>>>>> + array of a structure as a flexible array member at different levels.
>>>>>
>>>>> <code>-fstrict-flex-arrays</code> to control which trailing array
>>>>> members are streated as flexible arrays.
>>>>
>>>> Okay.
>>>>
>>>>>
>>>>> I've also just now noticed that there's now a flag_strict_flex_arrays
>>>>> check in the middle-end (in array bound diagnostics) but this option
>>>>> isn't streamed or handled with LTO. I think you want to replace that
>>>>> with the appropriate DECL_NOT_FLEXARRAY check.
>>>>
>>>> We need to know the level value of the strict_flex_arrays on the struct
>>>> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY
>>>> does not include such info. So, what should I do? Streaming the
>>>> flag_strict_flex_arrays with LTO?
>>>
>>> But you do
>>>
>>> if (compref)
>>> {
>>> /* Try to determine special array member type for this
>>> COMPONENT_REF. */
>>> sam = component_ref_sam_type (arg);
>>> /* Get the level of strict_flex_array for this array field. */
>>> tree afield_decl = TREE_OPERAND (arg, 1);
>>> strict_flex_array_level = strict_flex_array_level_of (afield_decl);
>>>
>>> I see that function doesn't look at DECL_NOT_FLEXARRAY but just
>>> checks attributes (those are streamed in LTO).
>>
>> Yes, checked both flag_strict_flex_arrays and attributes.
>>
>> There are two places in middle end calling ?strict_flex_array_level_of? function,
>> one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?.
>> Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places?
>
> I wonder if that function should check DECL_NOT_FLEXARRAY?
The function “strict_flex_array_level_of” is intended to query the LEVEL of strict_flex_array, only check DECL_NOT_FLEXARRAY is not enough.
So, I think the major question here is:
Do we need the LEVEL of strict_flex_array information in the Middle end?
The current major use of LEVEL of strict_flex_array in the middle end is two places:
1. In the routine “component_ref_size”: to determine the size of the trailing array based on the level of the strict_flex_array.
2. In the routine “array_bounds_checker::check_array_ref”: to issue different information for -Wstrict-flex-array based on different level.
Just double checked the above 1, and 2. Without LEVEL of strict_flex_array info, 1 should be fine
2, as you mentioned previously, the major impact will be that the LEVEL information is lost in the issued message, but that might be not a big
issue.
So, I will try to eliminate the reference to “flag_strict_flex_array” in the middle end, replace it with “DECL_NOT_FLEXARRAY”, and come up with
an updated patch for this change.
How do you think?
>
>>>
>>> OK, so I suppose the diagnostic itself would become just less precise
>>> as in "trailing array %qT should not be used as a flexible array member"
>>> without the "for level N and above" part of the diagnostic?
>>
>> Yes, that might be the major impact.
>>
>> If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter?
>
> I think the main information is preserved in diagnosing the flex vs.
> non-flex array assumption.
Yes. Agreed.
>
>>>
>>>>> We might also want
>>>>> to see how inlining accesses from TUs with different -fstrict-flex-arrays
>>>>> setting behaves when accessing the same structure (and whether we might
>>>>> want to issue an ODR style diagnostic there).
>>>
>>> This mixing also means streaming -fstrict-flex-arrays won't be of much
>>> help in general.
>>
>> Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it?
>
> I think in similar situations we try to DWIM, but in some cases it will
> result in "garbage" behavior. I don't think there's anything we can
> do here besides trying to diagnose such mismatches with -flto at the WPA
> stage.
Shall we issue warning for such mismatches? Where is the place I can add such warnings?
thanks.
Qing
>
> Richard.
On Mon, 9 Jan 2023, Qing Zhao wrote:
>
>
> > On Jan 9, 2023, at 2:11 AM, Richard Biener <rguenther@suse.de> wrote:
> >
> > On Thu, 22 Dec 2022, Qing Zhao wrote:
> >
> >>
> >>
> >>> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote:
> >>>
> >>> On Wed, 21 Dec 2022, Qing Zhao wrote:
> >>>
> >>>> Hi, Richard,
> >>>>
> >>>> Thanks a lot for your comments.
> >>>>
> >>>>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote:
> >>>>>
> >>>>> On Tue, 20 Dec 2022, Qing Zhao wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
> >>>>>>
> >>>>>> Let me know if you have any comment or suggestions.
> >>>>>
> >>>>> Some copy editing below
> >>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>> Qing.
> >>>>>>
> >>>>>> =======================================
> >>>>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
> >>>>>> From: Qing Zhao <qing.zhao@oracle.com>
> >>>>>> Date: Tue, 20 Dec 2022 16:13:04 +0000
> >>>>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
> >>>>>>
> >>>>>> ---
> >>>>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++
> >>>>>> 1 file changed, 15 insertions(+)
> >>>>>>
> >>>>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
> >>>>>> index 689178f9..47b3d40f 100644
> >>>>>> --- a/htdocs/gcc-13/changes.html
> >>>>>> +++ b/htdocs/gcc-13/changes.html
> >>>>>> @@ -39,6 +39,10 @@ a work-in-progress.</p>
> >>>>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
> >>>>>> and the option is ignored right now.</li>
> >>>>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
> >>>>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
> >>>>>> + accesses to trailing struct members of one-element array type anymore. Please
> >>>>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
> >>>>>> + trailing arrays of structures as flexible array members. </li>
> >>>>>
> >>>>> "Instead it diagnoses accesses to trailing arrays according to
> >>>>> <code>-fstrict-flex-arrays</code>."
> >>>>
> >>>> Okay.
> >>>>>
> >>>>>> </ul>
> >>>>>>
> >>>>>>
> >>>>>> @@ -409,6 +413,17 @@ a work-in-progress.</p>
> >>>>>> <h2>Other significant improvements</h2>
> >>>>>>
> >>>>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
> >>>>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
> >>>>>> +
> >>>>>> +<ul>
> >>>>>> + <li>GCC can now control when to treat the trailing array of a structure as a
> >>>>>> + flexible array member for the purpose of accessing the elements of such
> >>>>>> + an array. By default, all trailing arrays of structures are treated as
> >>>>>
> >>>>> all trailing arrays in aggregates are treated
> >>>> Okay.
> >>>>>
> >>>>>> + flexible array members. Use the new command-line option
> >>>>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
> >>>>>> + array of a structure as a flexible array member at different levels.
> >>>>>
> >>>>> <code>-fstrict-flex-arrays</code> to control which trailing array
> >>>>> members are streated as flexible arrays.
> >>>>
> >>>> Okay.
> >>>>
> >>>>>
> >>>>> I've also just now noticed that there's now a flag_strict_flex_arrays
> >>>>> check in the middle-end (in array bound diagnostics) but this option
> >>>>> isn't streamed or handled with LTO. I think you want to replace that
> >>>>> with the appropriate DECL_NOT_FLEXARRAY check.
> >>>>
> >>>> We need to know the level value of the strict_flex_arrays on the struct
> >>>> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY
> >>>> does not include such info. So, what should I do? Streaming the
> >>>> flag_strict_flex_arrays with LTO?
> >>>
> >>> But you do
> >>>
> >>> if (compref)
> >>> {
> >>> /* Try to determine special array member type for this
> >>> COMPONENT_REF. */
> >>> sam = component_ref_sam_type (arg);
> >>> /* Get the level of strict_flex_array for this array field. */
> >>> tree afield_decl = TREE_OPERAND (arg, 1);
> >>> strict_flex_array_level = strict_flex_array_level_of (afield_decl);
> >>>
> >>> I see that function doesn't look at DECL_NOT_FLEXARRAY but just
> >>> checks attributes (those are streamed in LTO).
> >>
> >> Yes, checked both flag_strict_flex_arrays and attributes.
> >>
> >> There are two places in middle end calling ?strict_flex_array_level_of? function,
> >> one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?.
> >> Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places?
> >
> > I wonder if that function should check DECL_NOT_FLEXARRAY?
>
> The function ?strict_flex_array_level_of? is intended to query the LEVEL of strict_flex_array, only check DECL_NOT_FLEXARRAY is not enough.
>
> So, I think the major question here is:
>
> Do we need the LEVEL of strict_flex_array information in the Middle end?
>
> The current major use of LEVEL of strict_flex_array in the middle end is two places:
>
> 1. In the routine ?component_ref_size?: to determine the size of the trailing array based on the level of the strict_flex_array.
> 2. In the routine ?array_bounds_checker::check_array_ref?: to issue different information for -Wstrict-flex-array based on different level.
>
>
> Just double checked the above 1, and 2. Without LEVEL of strict_flex_array info, 1 should be fine
> 2, as you mentioned previously, the major impact will be that the LEVEL information is lost in the issued message, but that might be not a big
> issue.
>
> So, I will try to eliminate the reference to ?flag_strict_flex_array? in the middle end, replace it with ?DECL_NOT_FLEXARRAY?, and come up with
> an updated patch for this change.
>
> How do you think?
Yes, that sounds good.
> >
> >>>
> >>> OK, so I suppose the diagnostic itself would become just less precise
> >>> as in "trailing array %qT should not be used as a flexible array member"
> >>> without the "for level N and above" part of the diagnostic?
> >>
> >> Yes, that might be the major impact.
> >>
> >> If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter?
> >
> > I think the main information is preserved in diagnosing the flex vs.
> > non-flex array assumption.
> Yes. Agreed.
>
> >
> >>>
> >>>>> We might also want
> >>>>> to see how inlining accesses from TUs with different -fstrict-flex-arrays
> >>>>> setting behaves when accessing the same structure (and whether we might
> >>>>> want to issue an ODR style diagnostic there).
> >>>
> >>> This mixing also means streaming -fstrict-flex-arrays won't be of much
> >>> help in general.
> >>
> >> Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it?
> >
> > I think in similar situations we try to DWIM, but in some cases it will
> > result in "garbage" behavior. I don't think there's anything we can
> > do here besides trying to diagnose such mismatches with -flto at the WPA
> > stage.
>
> Shall we issue warning for such mismatches? Where is the place I can add such warnings?
I'm not sure - we'd have to restrict it to "used" types and in principle
only when actual objects pass from one TU to another with different
flex-array semantics. Otherwise we'll risk tons of diagnostics when
people "forget" -fstrict-flex-arrays on some TUs but pull in common
headers.
The C++ ODR diagnostics reside in ipa-devirt.cc, I'm not sure diagnostics
on flex arrays would fit there.
I just wanted to bring this up, I do not have a good idea how or where
to implement it.
Richard.
> thanks.
>
> Qing
> >
> > Richard.
>
>
> On Jan 10, 2023, at 3:06 AM, Richard Biener <rguenther@suse.de> wrote:
>
> On Mon, 9 Jan 2023, Qing Zhao wrote:
>
>>
>>
>>> On Jan 9, 2023, at 2:11 AM, Richard Biener <rguenther@suse.de> wrote:
>>>
>>> On Thu, 22 Dec 2022, Qing Zhao wrote:
>>>
>>>>
>>>>
>>>>> On Dec 22, 2022, at 2:09 AM, Richard Biener <rguenther@suse.de> wrote:
>>>>>
>>>>> On Wed, 21 Dec 2022, Qing Zhao wrote:
>>>>>
>>>>>> Hi, Richard,
>>>>>>
>>>>>> Thanks a lot for your comments.
>>>>>>
>>>>>>> On Dec 21, 2022, at 2:12 AM, Richard Biener <rguenther@suse.de> wrote:
>>>>>>>
>>>>>>> On Tue, 20 Dec 2022, Qing Zhao wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2 changes in gcc-13/changes.html.
>>>>>>>>
>>>>>>>> Let me know if you have any comment or suggestions.
>>>>>>>
>>>>>>> Some copy editing below
>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Qing.
>>>>>>>>
>>>>>>>> =======================================
>>>>>>>> From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
>>>>>>>> From: Qing Zhao <qing.zhao@oracle.com>
>>>>>>>> Date: Tue, 20 Dec 2022 16:13:04 +0000
>>>>>>>> Subject: [PATCH] gcc-13/changes: Mention -fstrict-flex-arrays and its impact.
>>>>>>>>
>>>>>>>> ---
>>>>>>>> htdocs/gcc-13/changes.html | 15 +++++++++++++++
>>>>>>>> 1 file changed, 15 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
>>>>>>>> index 689178f9..47b3d40f 100644
>>>>>>>> --- a/htdocs/gcc-13/changes.html
>>>>>>>> +++ b/htdocs/gcc-13/changes.html
>>>>>>>> @@ -39,6 +39,10 @@ a work-in-progress.</p>
>>>>>>>> <li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
>>>>>>>> and the option is ignored right now.</li>
>>>>>>>> <li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
>>>>>>>> + <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
>>>>>>>> + accesses to trailing struct members of one-element array type anymore. Please
>>>>>>>> + add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
>>>>>>>> + trailing arrays of structures as flexible array members. </li>
>>>>>>>
>>>>>>> "Instead it diagnoses accesses to trailing arrays according to
>>>>>>> <code>-fstrict-flex-arrays</code>."
>>>>>>
>>>>>> Okay.
>>>>>>>
>>>>>>>> </ul>
>>>>>>>>
>>>>>>>>
>>>>>>>> @@ -409,6 +413,17 @@ a work-in-progress.</p>
>>>>>>>> <h2>Other significant improvements</h2>
>>>>>>>>
>>>>>>>> <!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
>>>>>>>> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
>>>>>>>> +
>>>>>>>> +<ul>
>>>>>>>> + <li>GCC can now control when to treat the trailing array of a structure as a
>>>>>>>> + flexible array member for the purpose of accessing the elements of such
>>>>>>>> + an array. By default, all trailing arrays of structures are treated as
>>>>>>>
>>>>>>> all trailing arrays in aggregates are treated
>>>>>> Okay.
>>>>>>>
>>>>>>>> + flexible array members. Use the new command-line option
>>>>>>>> + <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
>>>>>>>> + array of a structure as a flexible array member at different levels.
>>>>>>>
>>>>>>> <code>-fstrict-flex-arrays</code> to control which trailing array
>>>>>>> members are streated as flexible arrays.
>>>>>>
>>>>>> Okay.
>>>>>>
>>>>>>>
>>>>>>> I've also just now noticed that there's now a flag_strict_flex_arrays
>>>>>>> check in the middle-end (in array bound diagnostics) but this option
>>>>>>> isn't streamed or handled with LTO. I think you want to replace that
>>>>>>> with the appropriate DECL_NOT_FLEXARRAY check.
>>>>>>
>>>>>> We need to know the level value of the strict_flex_arrays on the struct
>>>>>> field to issue proper warnings at different levels. DECL_NOT_FLEXARRAY
>>>>>> does not include such info. So, what should I do? Streaming the
>>>>>> flag_strict_flex_arrays with LTO?
>>>>>
>>>>> But you do
>>>>>
>>>>> if (compref)
>>>>> {
>>>>> /* Try to determine special array member type for this
>>>>> COMPONENT_REF. */
>>>>> sam = component_ref_sam_type (arg);
>>>>> /* Get the level of strict_flex_array for this array field. */
>>>>> tree afield_decl = TREE_OPERAND (arg, 1);
>>>>> strict_flex_array_level = strict_flex_array_level_of (afield_decl);
>>>>>
>>>>> I see that function doesn't look at DECL_NOT_FLEXARRAY but just
>>>>> checks attributes (those are streamed in LTO).
>>>>
>>>> Yes, checked both flag_strict_flex_arrays and attributes.
>>>>
>>>> There are two places in middle end calling ?strict_flex_array_level_of? function,
>>>> one inside ?array_bounds_checker::check_array_ref?, another one inside ?component_ref_size?.
>>>> Shall we check DECL_NOT_FLEXARRAY field instead of calling ?strict_flex_array_level_of? in both places?
>>>
>>> I wonder if that function should check DECL_NOT_FLEXARRAY?
>>
>> The function ?strict_flex_array_level_of? is intended to query the LEVEL of strict_flex_array, only check DECL_NOT_FLEXARRAY is not enough.
>>
>> So, I think the major question here is:
>>
>> Do we need the LEVEL of strict_flex_array information in the Middle end?
>>
>> The current major use of LEVEL of strict_flex_array in the middle end is two places:
>>
>> 1. In the routine ?component_ref_size?: to determine the size of the trailing array based on the level of the strict_flex_array.
>> 2. In the routine ?array_bounds_checker::check_array_ref?: to issue different information for -Wstrict-flex-array based on different level.
>>
>>
>> Just double checked the above 1, and 2. Without LEVEL of strict_flex_array info, 1 should be fine
>> 2, as you mentioned previously, the major impact will be that the LEVEL information is lost in the issued message, but that might be not a big
>> issue.
>>
>> So, I will try to eliminate the reference to ?flag_strict_flex_array? in the middle end, replace it with ?DECL_NOT_FLEXARRAY?, and come up with
>> an updated patch for this change.
>>
>> How do you think?
>
> Yes, that sounds good.
Will do that.
>
>>>
>>>>>
>>>>> OK, so I suppose the diagnostic itself would become just less precise
>>>>> as in "trailing array %qT should not be used as a flexible array member"
>>>>> without the "for level N and above" part of the diagnostic?
>>>>
>>>> Yes, that might be the major impact.
>>>>
>>>> If only check DECL_NOT_FLEXARRAY, we will lose such information. Does that matter?
>>>
>>> I think the main information is preserved in diagnosing the flex vs.
>>> non-flex array assumption.
>> Yes. Agreed.
>>
>>>
>>>>>
>>>>>>> We might also want
>>>>>>> to see how inlining accesses from TUs with different -fstrict-flex-arrays
>>>>>>> setting behaves when accessing the same structure (and whether we might
>>>>>>> want to issue an ODR style diagnostic there).
>>>>>
>>>>> This mixing also means streaming -fstrict-flex-arrays won't be of much
>>>>> help in general.
>>>>
>>>> Then under such situation, i.e, different -fstrict-flex-arrays levels for the same structure from different TUs, how should we handle it?
>>>
>>> I think in similar situations we try to DWIM, but in some cases it will
>>> result in "garbage" behavior. I don't think there's anything we can
>>> do here besides trying to diagnose such mismatches with -flto at the WPA
>>> stage.
>>
>> Shall we issue warning for such mismatches? Where is the place I can add such warnings?
>
> I'm not sure - we'd have to restrict it to "used" types and in principle
> only when actual objects pass from one TU to another with different
> flex-array semantics. Otherwise we'll risk tons of diagnostics when
> people "forget" -fstrict-flex-arrays on some TUs but pull in common
> headers.
>
> The C++ ODR diagnostics reside in ipa-devirt.cc, I'm not sure diagnostics
> on flex arrays would fit there.
>
> I just wanted to bring this up, I do not have a good idea how or where
> to implement it.
Thanks for the information. Will study this a little bit later.
Qing
>
> Richard.
>
>> thanks.
>>
>> Qing
>>>
>>> Richard.
>>
>>
>
> --
> Richard Biener <rguenther@suse.de>
> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
> Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
> HRB 36809 (AG Nuernberg)
On Tue, 20 Dec 2022, Qing Zhao via Gcc-patches wrote:
> +<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
Please note that ids must not contain white space.
Would you mind following up making this "flexiblearray" or similiar?
Thank you,
Gerald
Thanks for the comment.
I just committed the following:
From fc681f5412c421ff9609aea448310106d2570fd5 Mon Sep 17 00:00:00 2001
From: Qing Zhao <qing.zhao@oracle.com>
Date: Tue, 17 Jan 2023 15:52:15 +0000
Subject: [PATCH] gcc13/changes: update id 'flexible array' to
'flexible-arrays' since ids must not contain white space
---
htdocs/gcc-13/changes.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 08e36fb3..ca9cd2da 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -438,7 +438,7 @@ a work-in-progress.</p>
<h2>Other significant improvements</h2>
<!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
-<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
+<h3 id="flexible-arrays">Treating trailing arrays as flexible array members</h3>
<ul>
<li>GCC can now control when to treat the trailing array of a structure as a
@@ -39,6 +39,10 @@ a work-in-progress.</p>
<li>Legacy debug info compression option <code>-gz=zlib-gnu</code> was removed
and the option is ignored right now.</li>
<li>New debug info compression option value <code>-gz=zstd</code> has been added.</li>
+ <li><code>-Warray-bounds=2</code> will no longer issue warnings for out of bounds
+ accesses to trailing struct members of one-element array type anymore. Please
+ add <code>-fstrict-flex-arrays=level</code> to control how the compiler treat
+ trailing arrays of structures as flexible array members. </li>
</ul>
@@ -409,6 +413,17 @@ a work-in-progress.</p>
<h2>Other significant improvements</h2>
<!-- <h3 id="uninitialized">Eliminating uninitialized variables</h3> -->
+<h3 id="flexible array">Treating trailing arrays as flexible array members</h3>
+
+<ul>
+ <li>GCC can now control when to treat the trailing array of a structure as a
+ flexible array member for the purpose of accessing the elements of such
+ an array. By default, all trailing arrays of structures are treated as
+ flexible array members. Use the new command-line option
+ <code>-fstrict-flex-array=level</code> to control how GCC treats the trailing
+ array of a structure as a flexible array member at different levels.
+ </li>
+</ul>
<!-- .................................................................. -->
<!-- <h2 id="13.1">GCC 13.1</h2> -->