From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2001:67c:2178:6::1c]) by sourceware.org (Postfix) with ESMTPS id 51E483858D1E for ; Thu, 22 Dec 2022 07:09:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 51E483858D1E 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-out1.suse.de (Postfix) with ESMTP id 067C18CD34; Thu, 22 Dec 2022 07:09:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1671692972; 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=wvS5WbpRISZ2eE+yUcKKxCM8fPuSx8wik2nrHhA1K1Q=; b=VvIdv5yZ2F9FiVtbbxrx886cZ19QX2Lw/BJzna9h5JiwW6RBTHbXelBkeBFgHhYth6mSEM tTJtfX3TOAepOQ/B5Ei2G8VEGp8nuNfpJJOpXYWs5OM0Pm/adsoKURV1OWRLcDLpmvDiBk jbwffguHReex3qUYoNlAFDBFuT/P8Ik= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1671692972; 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=wvS5WbpRISZ2eE+yUcKKxCM8fPuSx8wik2nrHhA1K1Q=; b=vI/l3NjL3C9xfk5eAPw6cOfndmVASjaMbN53bZgnz/kVqcRFSC01E4b8ICttk5x2b5S+8t kkrnler0fADeA1Bw== 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 DE0852C141; Thu, 22 Dec 2022 07:09:31 +0000 (UTC) Date: Thu, 22 Dec 2022 07:09:31 +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: <7EE40B3B-7A01-48A1-B4BE-B0E3103C31A3@oracle.com> Message-ID: References: <7EE40B3B-7A01-48A1-B4BE-B0E3103C31A3@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 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). 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. > > -- Richard Biener SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)