public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Qing Zhao <qing.zhao@oracle.com>
To: gcc-patches Paul A Clarke via <gcc-patches@gcc.gnu.org>
Cc: jakub Jelinek <jakub@redhat.com>,
	Richard Biener <rguenther@suse.de>,
	martin Sebor <msebor@gmail.com>,
	Kees Cook <keescook@chromium.org>,
	"Joseph@codesourcery.com" <Joseph@codesourcery.com>
Subject: [GCC13][Patch][V2][0/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836
Date: Tue, 19 Jul 2022 14:07:44 +0000	[thread overview]
Message-ID: <EC1BCFDF-E10C-45EA-9CEA-B5C4291CDA49@oracle.com> (raw)

Hi, 

Based on the previous discussion on the Version 1 of the patch:

https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597350.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598010.html

We decided:

*****User interface:
.  command line option in C/C++:
    -fstrict-flex-array[=N]       (N=0, 1, 2, 3)
.  decl attribute for FIELD_DECL:
    strict_flex_array (N)      (N=0, 1, 2, 3)

*****Implementation:

1.  Add a new IR flag “DECL_NOT_FLEXARRAY” to FIELD_DECL; 

2.  In C/C++ FE, set the new flag “DECL_NOT_FLEXARRAY” for a FIELD_DECL based on [0], [1],
   [] and the option -fstrict-flex-array, the attribute strict_flex_array and whether it’s the last field of
   the DECL_CONTEXT.

3.  In Middle end,   update any place that treats trailing array as flexible array member with the 
    new flag  DECL_NOT_FLEXARRAY + array_at_struct_end_p to control the behavior with
    Multiple level consistently. 

Then the above implementation will be divided into the following 3 parts:

Part A:  1 + 2
Part B:  In Middle end, use the new flag in tree-object-size.cc to resolve PR101836, then kernel can use __FORTIFY_SOURCE correctly after this;
Part C:  in Middle end, use the new flag in all other places that use “array_at_struct_end_p” or “component_ref_size” to make GCC consistently 
            behave for trailing array. 

This set of patches (2 patches in total, the #1 is for Part A, and #2 is for Part B) are for the above Part A and Part B.   

NOTE: After this set of patches, the one major issue remained in GCC is, different phases that call either “array_at_struct_end_p” or “component_ref_size” behave
inconsistently on the default behavior of what’s a flexible array member, some phases treat all trailing array as flexible array member by default, and some
phases treat trailing [], [0], [1] as flexible array member by default. Such inconsistency need to be resolved in Part C. 

I have bootstrapped and regression tested on both aarch64 and x86, no issues.

Let me know if you have any comments on the patches.

Thanks.

Qing

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

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=EC1BCFDF-E10C-45EA-9CEA-B5C4291CDA49@oracle.com \
    --to=qing.zhao@oracle.com \
    --cc=Joseph@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=keescook@chromium.org \
    --cc=msebor@gmail.com \
    --cc=rguenther@suse.de \
    /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).