From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path:
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29])
by sourceware.org (Postfix) with ESMTPS id E1DB73858D33
for ; Mon, 9 Jan 2023 07:11:06 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E1DB73858D33
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
by smtp-out2.suse.de (Postfix) with ESMTP id 010DA76BAA;
Mon, 9 Jan 2023 07:11:02 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa;
t=1673248262; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=Ehcq5wPYgQ1PTUgIcfGOF58Eo7/2JIiHr2PoahnXSmc=;
b=Jm+ERqkAE3q5S8XCtWu5yAIRjXR9MWJJKtUdeSCeY0CIASulx00ETOuZdKVGvRNcY0da0H
pCWsiWc3STEU1CTY2In6bJ1c0zo58OYu4Yk4YEV+igX4aFBtkIjM5llcc+Nf8PET5bW03I
egqgSS8KcVWHZEKdGUK8Qc22HJsxKso=
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de;
s=susede2_ed25519; t=1673248262;
h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=Ehcq5wPYgQ1PTUgIcfGOF58Eo7/2JIiHr2PoahnXSmc=;
b=KjvRrhhV40HtOT1LP0cqC/RqRESlvQjHcGNjIUf8cSJYcgsLSM7g0AM5NsEli4SWucR7nv
2VEBSAb7PMOAGmAw==
Received: from wotan.suse.de (wotan.suse.de [10.160.0.1])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by relay2.suse.de (Postfix) with ESMTPS id D5DE12C141;
Mon, 9 Jan 2023 07:11:01 +0000 (UTC)
Date: Mon, 9 Jan 2023 07:11:01 +0000 (UTC)
From: Richard Biener
To: Qing Zhao
cc: gcc Patches
Subject: Re: gcc-13/changes.html: Mention -fstrict-flex-arrays and its
impact
In-Reply-To: <47CF80FD-1B6B-4024-B493-79D45859E65A@oracle.com>
Message-ID:
References: <7EE40B3B-7A01-48A1-B4BE-B0E3103C31A3@oracle.com>
<47CF80FD-1B6B-4024-B493-79D45859E65A@oracle.com>
User-Agent: Alpine 2.22 (LSU 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id:
On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>
> > On Dec 22, 2022, at 2:09 AM, Richard Biener 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 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
> >>>> 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.
> >>>> Legacy debug info compression option -gz=zlib-gnu
was removed
> >>>> and the option is ignored right now.
> >>>> New debug info compression option value -gz=zstd
has been added.
> >>>> + -Warray-bounds=2
will no longer issue warnings for out of bounds
> >>>> + accesses to trailing struct members of one-element array type anymore. Please
> >>>> + add -fstrict-flex-arrays=level
to control how the compiler treat
> >>>> + trailing arrays of structures as flexible array members.
> >>>
> >>> "Instead it diagnoses accesses to trailing arrays according to
> >>> -fstrict-flex-arrays
."
> >>
> >> Okay.
> >>>
> >>>>
> >>>>
> >>>>
> >>>> @@ -409,6 +413,17 @@ a work-in-progress.
> >>>> Other significant improvements
> >>>>
> >>>>
> >>>> +Treating trailing arrays as flexible array members
> >>>> +
> >>>> +
> >>>> + - 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
> >>>> +
-fstrict-flex-array=level
to control how GCC treats the trailing
> >>>> + array of a structure as a flexible array member at different levels.
> >>>
> >>> -fstrict-flex-arrays
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.