public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Qing Zhao <qing.zhao@oracle.com>
To: Martin Sebor <msebor@gmail.com>, Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches Paul A Clarke via <gcc-patches@gcc.gnu.org>,
	kees Cook <keescook@chromium.org>
Subject: Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size
Date: Thu, 30 Jun 2022 14:07:51 +0000	[thread overview]
Message-ID: <CE3D3114-DCDC-4EC9-A913-5343A4173BEE@oracle.com> (raw)
In-Reply-To: <a9ac0f0c-b94c-f38a-a036-af54645653a3@gmail.com>



> On Jun 29, 2022, at 5:14 PM, Martin Sebor <msebor@gmail.com> wrote:
> 
> On 6/28/22 13:01, Qing Zhao wrote:
>>> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>> 
>>> On Tue, Jun 28, 2022 at 06:29:01PM +0000, Qing Zhao wrote:
>>>> 
>>>> 
>>>>> On Jun 28, 2022, at 2:22 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>>> 
>>>>> On Tue, Jun 28, 2022 at 06:15:58PM +0000, Qing Zhao wrote:
>>>>>>> Because the flag just tells whether some array shouldn't be treated as (poor man's)
>>>>>>> flexible array member.  We still need to find out if some FIELD_DECL is to
>>>>>>> be treated like a flexible array member, which is a minority of
>>>>>>> COMPONENT_REFs.
>>>>>>> struct S { int a; char b[0]; int c; } s;
>>>>>>> struct T { int d; char e[]; };
>>>>>>> struct U { int f; struct T g; int h; } u;
>>>>>>> Neither s.b nor u.g.e is to be treated like flexible array member,
>>>>>>> no matter what -fstrict-flex-array= option is used.
>>>>>> 
>>>>>> Then, to resolve this issue, we might need a opposite  flag DECL_IS_FLEXARRAY in FIELD_DECL?
>>>>>> 
>>>>>> The default is FALSE for all FIELD_DECL.
>>>>> 
>>>>> Doesn't matter whether it is positive or negative, you still need to analyze
>>>>> it.  See the above example.  If you have struct T t; and test t.e, then it
>>>>> is flexarray.  But u.g.e is not, even when the COMPONENT_REF refers to the
>>>>> same FIELD_DECL.  In the t.e case e is the very last field, in the latter
>>>>> case u.g.e is the last field in struct T, but struct U has the h field after
>>>> 
>>>> So, do you mean that the current FE analysis will not be able to decide whether a specific array field is at the end of the enclosing structure?
>>>> Only the middle end can decide this ?
>>> 
>>> Well, anything that analyzes it, can be in the FE or middle-end, but there
>>> is no place to store it for later.
>> Then I am a little confused:
>> If the FE can decide wether an array field is at the end of the enclosing structure,  then combined with whether it’s a [0], [1] or [], and which level of -fstrict-flex-array,
>> The FE should be able to decide whether this array field is a flexible array member or not, then set the flag DECL_IS_FLEXARRAY (or DECL_NOT_FLEXARRAY).
>> The new flag is the place to store such info, right?
>> Do I miss anything here?
> 
> I think the problem is that there is just one FIELD_DECL for member
> M of a given type T but there can be more than one instance of that
> member, one in each struct that has a subobject of T as its own
> member.  Whether M is or isn't a (valid) flexible array member
> varies between the two instances.

Okay, I see. 
A FIELD_DECL might be shared by multiple structure or unions, and whether 
it’s a flexible array member varies between different enclosing structures or unions.
Therefore FIELD_DECL cannot carry the flexible array member information accurately. 

Then, how about encoding the flexible array member information into the enclosing structure or union? 


Another thing is:  All this complexity is caused by GNU extension which permits the flexible array 
member not at the end of the struct. (As I mentioned in a previous email, I listed here again)

For example the following two examples:

1. [opc@qinzhao-ol8u3-x86 trailing_array]$ cat t1.c
struct AX
{
  int n;
  short ax[];
  int m;
};

void warn_ax_local (struct AX *p)
{
  p->ax[2] = 0;   
}

2. [opc@qinzhao-ol8u3-x86 trailing_array]$ cat t2.c
struct AX
{
  int n;
  short ax[];
};

struct UX
{
  struct AX b;
  int m;
};

void warn_ax_local (struct AX *p, struct UX *q)
{
  p->ax[2] = 0;   
  q->b.ax[2] = 0;
}

[opc@qinzhao-ol8u3-x86 trailing_array]$ gcc -O2 -Wall t1.c -S
t4.c:4:9: error: flexible array member not at end of struct
    4 |   short ax[];

[opc@qinzhao-ol8u3-x86 trailing_array]$ gcc -O2 -Wall t2.c -S

It’s clear to see that in the above t1.c,  GCC  reports error when the flexible array member is Not at the end of the structure  (AX) that immediately enclosing the field.
However, for t2.c, when the flexible array member is Not at the end of the structure that does not immediately enclosing it (UX), then it’s accepted.   

I am very confused about t2.c, is the struct UX a correct declaration? 

Thanks.

Qing

> 
> Martin


  reply	other threads:[~2022-06-30 14:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-27 14:19 Qing Zhao
2022-06-28  7:16 ` Richard Biener
2022-06-28 15:03   ` Qing Zhao
2022-06-28 15:08     ` Jakub Jelinek
2022-06-28 15:59       ` Qing Zhao
2022-06-28 16:43         ` Jakub Jelinek
2022-06-28 18:15           ` Qing Zhao
2022-06-28 18:22             ` Jakub Jelinek
2022-06-28 18:29               ` Qing Zhao
2022-06-28 18:49                 ` Jakub Jelinek
2022-06-28 19:01                   ` Qing Zhao
2022-06-29 21:14                     ` Martin Sebor
2022-06-30 14:07                       ` Qing Zhao [this message]
2022-06-30 14:24                         ` Richard Biener
2022-06-30 15:31                           ` Qing Zhao
2022-06-30 17:03                             ` Jakub Jelinek
2022-06-30 19:30                               ` Qing Zhao
2022-07-01  6:49                                 ` Richard Biener
2022-07-01 12:55                                   ` Qing Zhao
2022-07-01 12:58                                     ` Richard Biener
2022-07-01 13:40                                       ` Qing Zhao
2022-07-01 12:59                                     ` Jakub Jelinek
2022-07-01 14:01                                       ` Qing Zhao
2022-07-01 15:32                                         ` Martin Sebor
2022-07-04  6:49                                           ` Richard Biener
2022-07-06 14:20                                             ` Qing Zhao
2022-07-07  8:02                                               ` Richard Biener
2022-07-07 13:33                                                 ` Qing Zhao
2022-06-29 20:45           ` Qing Zhao
2022-06-28 16:21   ` Martin Sebor

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=CE3D3114-DCDC-4EC9-A913-5343A4173BEE@oracle.com \
    --to=qing.zhao@oracle.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=keescook@chromium.org \
    --cc=msebor@gmail.com \
    /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).