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).