public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Qing Zhao <qing.zhao@oracle.com>
Cc: richard Biener <rguenther@suse.de>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"siddhesh@gotplt.org" <siddhesh@gotplt.org>,
	"keescook@chromium.org" <keescook@chromium.org>
Subject: Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]
Date: Wed, 8 Feb 2023 19:09:27 +0000	[thread overview]
Message-ID: <17bc7992-23b6-63dc-3a3a-1be016d3bbb@codesourcery.com> (raw)
In-Reply-To: <2AB95191-B5D9-41AC-916A-C57ED20DF55E@oracle.com>

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:

> But I noticed that “flexible_array_type_p” later was moved from FE to
>  middle-end and put into tree.cc, tree.h as a general utility routine, and to 
> 
> /* Determine whether TYPE is a structure with a flexible array member,
>    or a union containing such a structure (possibly recursively).  */
> 
> However, since this routine does not cover the cases when the structure 
> with flexible array member was recursively embedded into structures, (which we 
> agreed that it should be considered as a flexible sized type). 
> 
> Therefore, I feel that It might not be proper to include this routine in middle end 
> (and actually no other places In middle end use this routine so far).

I think we've established that diagnostics and at least some middle-end 
purposes need different conditions.  Diagnostics for nesting a structure 
with a flexible array member inside another structure should only count [] 
as a flexible array member, whereas permitting flexible array uses in the 
middle end should allow [0] and [1] under some circumstances (depending on 
command-line options).

> But:
> 
> struct flex0 { int n; int data[0]; };
> struct out_flex_end0 { int m; struct flex0 flex_data; }; 
> struct outer_flex_end0 { int p; struct out_flex_end0 out_flex_data; }; 
> 
> In the above, only “flex0” is flexible sized type by default. 
> But “out_flex_end0” and “out_flex_end0” are Not considered as flexible sized type by default? 

It would be OK (and I'm not saying here that this is necessarily 
desirable), since that's at the end of another structure rather than in 
the middle, to consider them flexible for the purposes of code generation.

What must be avoided is -pedantic diagnostics for

struct flex1 { int n; int data[1]; };
struct out_flex_end1 { int m; struct flex1 flex_data; };

regardless of whether considered flexible or not, since that's clearly 
valid in standard C.

-- 
Joseph S. Myers
joseph@codesourcery.com

  reply	other threads:[~2023-02-08 19:09 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31 14:11 [PATCH 0/2]PR101832: Handle component_ref to a structure/union field including flexible array member for builtin_object_size Qing Zhao
2023-01-31 14:11 ` [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Qing Zhao
2023-02-01 11:41   ` Richard Biener
2023-02-01 14:19     ` Qing Zhao
2023-02-02  8:07       ` Richard Biener
2023-02-02 13:52         ` Qing Zhao
2023-02-02 13:54           ` Richard Biener
2023-02-02 14:38             ` Qing Zhao
2023-02-03  7:49               ` Richard Biener
2023-02-03 13:17                 ` Qing Zhao
2023-02-06  9:31                   ` Richard Biener
2023-02-06 14:38                     ` Qing Zhao
2023-02-06 23:14                       ` Joseph Myers
2023-02-07 14:54                         ` Qing Zhao
2023-02-07 19:17                           ` Joseph Myers
2023-02-07 19:57                             ` Qing Zhao
2023-02-07 23:37                               ` Joseph Myers
2023-02-08 15:06                                 ` Qing Zhao
2023-02-08 19:09                                   ` Joseph Myers [this message]
2023-02-08 19:20                                     ` Siddhesh Poyarekar
2023-02-08 20:51                                       ` Joseph Myers
2023-02-08 22:53                                       ` Qing Zhao
2023-02-08 23:18                                     ` Qing Zhao
2023-02-09 14:40                                       ` Qing Zhao
2023-02-09 16:46                                         ` Kees Cook
2023-02-10 15:25                                           ` Qing Zhao
2023-02-09 10:35                                   ` Richard Biener
2023-02-09 13:44                                     ` Qing Zhao
2023-02-07 15:28                         ` Siddhesh Poyarekar
2023-02-07 15:38                           ` Qing Zhao
2023-02-01 16:48   ` Siddhesh Poyarekar
2023-02-01 18:20     ` Qing Zhao
2023-01-31 14:11 ` [PATCH 2/2] Documentation Update Qing Zhao
2023-02-01 16:55   ` Siddhesh Poyarekar
2023-02-01 18:24     ` Qing Zhao
2023-02-01 18:57       ` Siddhesh Poyarekar
2023-02-01 19:19         ` Qing Zhao
2023-02-02  8:33         ` Richard Biener
2023-02-02 14:31           ` Qing Zhao
2023-02-02 17:05             ` Kees Cook
2023-02-03 15:56               ` Jeff Law
2023-02-03  4:25           ` Siddhesh Poyarekar
2023-02-03 14:52             ` Qing Zhao
2023-02-03 20:55             ` Joseph Myers
2023-02-03 22:38               ` Qing Zhao
2023-05-25  1:22 [V8][PATCH 0/2]Accept and Handle the case when a structure including a FAM nested in another structure Qing Zhao
2023-05-25  1:22 ` [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Qing Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17bc7992-23b6-63dc-3a3a-1be016d3bbb@codesourcery.com \
    --to=joseph@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=keescook@chromium.org \
    --cc=qing.zhao@oracle.com \
    --cc=rguenther@suse.de \
    --cc=siddhesh@gotplt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).