[PATCH][x86][2/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is the 2nd patch of the total 3 patches set for providing the new feature -mzero-caller-saved-regs for linux kernel security improvement. This patch is for resolving the new regressions triggered by the first patch. This patch is to Add ix86_any_return_p to check simple_return in a PA

[PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is a PING for an old patch proposed by H. J. Lu on Oct, 2018: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg02079.html This is the first patch of the total 3 patches set, which provides the following new feature: -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all] co

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard And Dave: Thanks a lot for the review and comments. > On Apr 21, 2020, at 1:46 PM, Richard Sandiford > wrote: > > David Malcolm writes: >> On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote >>> >>> Please add: >>> >>> PR c/94230 Will do. >>> * common.opt:

[Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

. Documentation for this new option; 4. Update the testing case location-overflow-test-1.c to include the new hint. Please take a look at this new patch and let me know any new comment. thanks. Qing. gcc/ChangeLog: 2020-04-22 qing zhao PR c/94230 * common.opt: Add -flarge-source-files

Re: [Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard, > On Apr 23, 2020, at 1:27 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> --- >> gcc/c-family/c-indentation.c | 3 +++ >> gcc/common.opt |

[Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard, This is the 3rd version of the patch, updated based on your previous comments. Please take a look at it and let me know whether it’s okay to commit? Thanks a lot for all your help. Qing. gcc/ChangeLog: 2020-04-22 qing zhao PR c/94230 * common.opt: Add -flarge

[Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

. Qing gcc/c-family/ChangeLog: 2020-04-24 qing zhao * c-indentation.c (get_visual_column): Add a hint to use the new -flarge-source-files option. gcc/ChangeLog: 2020-04-24 qing zhao * common.opt: Add -flarge-source-files. * doc/invoke.texi: Document it

Re: [Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, David, > On Apr 24, 2020, at 5:36 PM, David Malcolm wrote: > > On Fri, 2020-04-24 at 17:22 -0500, Qing Zhao wrote: >> Hi, Dave, >> >> Thanks a lot for the review and comments. >> I just updated the patch with all your suggestions, bootstrapped it >>

PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is a PING for this patch for gcc11 stage 1. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html <https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html> Please take a look on it. Thanks. Qing > Begin forwarded message: > > From: Qing Zhao

Committed [Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

FYI. > On Apr 23, 2020, at 5:13 PM, David Malcolm wrote: > > May need updating to match the hint message. > > [...] > > This is OK for stage 1 with those nits fixed. I committed the updated patch with all the suggestions today to gcc11 stage1 as: https://gcc.gnu.org/g:530b44094354758d0dea537

Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Kees, > On May 4, 2020, at 1:21 PM, Kees Cook wrote: > > On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote: >> Hi, >> >> This is a PING for this patch for gcc11 stage 1. >> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html

The performance data for two different implementation of new security feature -ftrivial-auto-var-init

and future work. Thanks a lot for your help. Qing > On Dec 9, 2020, at 10:18 AM, Qing Zhao via Gcc-patches > wrote: > > The following are the approaches I will implement and compare: > > Our final goal is to keep the uninitialized warning and minimize the run-time > per

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

I am attaching my current (incomplete) patch to gcc for your reference. From a71eb73bee5857440c4ff67c4c82be115e0675cb Mon Sep 17 00:00:00 2001 From: qing zhao Date: Sat, 12 Dec 2020 00:02:28 +0100 Subject: [PATCH] First version of -ftrivial-auto-var-init --- gcc/common.opt| 35

Pointer width in GCC?

Hi, Is there an utility routine in GCC to query the pointer width of the current target? Whether it’s 32bit pointer or 64 bit pointer for the target? Thanks a lot for the help. Qing

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

intentionaly for performance purpose. ** adding complete testing cases; Please let me know if you have any objection on my current decision on implementing approach D. Thanks a lot for your help. Qing > On Jan 5, 2021, at 1:05 PM, Qing Zhao via Gcc-patches > wrote: > > Hi, >

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

> On Jan 13, 2021, at 1:39 AM, Richard Biener wrote: > > On Tue, 12 Jan 2021, Qing Zhao wrote: > >> Hi, >> >> Just check in to see whether you have any comments and suggestions on this: >> >> FYI, I have been continue with Approach D implementatio

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

> On Jan 13, 2021, at 9:10 AM, Richard Biener wrote: > > On Wed, 13 Jan 2021, Qing Zhao wrote: > >> >> >>> On Jan 13, 2021, at 1:39 AM, Richard Biener wrote: >>> >>> On Tue, 12 Jan 2021, Qing Zhao wrote: >>> >>>>

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

13, 2021, at 1:39 AM, Richard Biener wrote: > > On Tue, 12 Jan 2021, Qing Zhao wrote: > >> Hi, >> >> Just check in to see whether you have any comments and suggestions on this: >> >> FYI, I have been continue with Approach D implementation since last w

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

> On Jan 15, 2021, at 2:11 AM, Richard Biener wrote: > > > > On Thu, 14 Jan 2021, Qing Zhao wrote: > >> Hi, >> More data on code size and compilation time with CPU2017: >> Compilation time data: the numbers are the slowdown against the >&

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

> On Jan 15, 2021, at 11:22 AM, Richard Biener wrote: > > On January 15, 2021 5:16:40 PM GMT+01:00, Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >>> On Jan 15, 2021, at 2:11 AM, Richard Biener >> wrote: >>> >>&g

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

> On Jan 18, 2021, at 7:09 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>>>> D will keep all initialized aggregates as aggregates and live which >>>>> means stack will be allocated for it. With A the usual optimizations >>>&g

[patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

--enable-checking=yes,rtl,df,extra, no regression. Okay for commit? Qing From c2573c6c8552b7b4c2eedb0684ce48b5c11436ec Mon Sep 17 00:00:00 2001 From: qing zhao Date: Thu, 19 Nov 2020 16:46:50 +0100 Subject: [PATCH] rtl-optimization: Fix data flow maintenance bug in reg-stack.c [pr9] reg-stack

How to traverse all the local variables that declared in the current routine?

Hi, Does gcc provide an iterator to traverse all the local variables that are declared in the current routine? If not, what’s the best way to traverse the local variables? Thanks. Qing

Re: How to traverse all the local variables that declared in the current routine?

> On Nov 24, 2020, at 1:32 AM, Richard Biener > wrote: > > On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches > wrote: >> >> Hi, >> >> Does gcc provide an iterator to traverse all the local variables that are >> declared in the curren

Re: How to traverse all the local variables that declared in the current routine?

> On Nov 24, 2020, at 9:55 AM, Richard Biener > wrote: > > On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote: >> >> >> >>> On Nov 24, 2020, at 1:32 AM, Richard Biener >>> wrote: >>> >>> On Tue, Nov 24, 2020 at 12:05 AM Qi

Re: How to traverse all the local variables that declared in the current routine?

> On Nov 25, 2020, at 3:11 AM, Richard Biener > wrote: >> >> >> Hi, >> >> Does gcc provide an iterator to traverse all the local variables that are >> declared in the current routine? >> >> If not, what’s the best way to traverse the local variables? >> >> >> Depends on what for. There

Re: How to traverse all the local variables that declared in the current routine?

Hi, Martin, Thanks a lot for your suggestion. > On Nov 25, 2020, at 6:08 PM, Martin Sebor wrote: > > On 11/24/20 9:54 AM, Qing Zhao via Gcc-patches wrote: >>> On Nov 24, 2020, at 9:55 AM, Richard Biener >>> wrote: >>> >>> On

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

Hi, Jeff, Sorry for the late reply due to thanksgiving long weekend. > On Nov 25, 2020, at 1:37 PM, Jeff Law wrote: > > > > On 11/19/20 8:59 AM, Qing Zhao via Gcc-patches wrote: >> Hi, >> >> PR9 - ICE: in df_refs_verify, at df-scan.c:3991 with -O

Re: How to traverse all the local variables that declared in the current routine?

On Nov 30, 2020, at 11:18 AM, Martin Sebor wrote: Does gcc provide an iterator to traverse all the local variables that are declared in the current routine? If not, what’s the best way to traverse the local variables? >>> >>> Depends on what for. The

Re: How to traverse all the local variables that declared in the current routine?

Hi, Richard, Could you please comment on the following approach: Instead of adding the zero-initializer quite late at the pass “pass_expand”, we can add it as early as during gimplification. However, we will mark these new added zero-initializers as “artificial”. And passing this “artificial”

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 2, 2020, at 2:45 AM, Richard Biener wrote: > > On Tue, Dec 1, 2020 at 8:49 PM Qing Zhao wrote: >> >> Hi, Richard, >> >> Could you please comment on the following approach: >> >> Instead of adding the zero-initializer quite late at

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

> On Dec 1, 2020, at 6:16 PM, Jeff Law wrote: >>>> From c2573c6c8552b7b4c2eedb0684ce48b5c11436ec Mon Sep 17 00:00:00 2001 >>>> From: qing zhao >>>> Date: Thu, 19 Nov 2020 16:46:50 +0100 >>>> Subject: [PATCH] rtl-optimization: Fix dat

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

Thanks a lot for your review. I will commit the patch soon. Qing > On Dec 2, 2020, at 12:27 PM, Jeff Law wrote: > > > > On 12/2/20 9:32 AM, Qing Zhao wrote: >> >>> So we are clearing the x87 registers with that option. Hence the change >>> in reg-

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 3, 2020, at 2:45 AM, Richard Biener wrote: > > On Wed, Dec 2, 2020 at 4:36 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >> >> On Dec 2, 2020, at 2:45 AM, Richard Biener >> wrote: >> >> On Tue, Dec

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 3, 2020, at 10:36 AM, Richard Biener > wrote: > > On December 3, 2020 5:07:28 PM GMT+01:00, Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >>>> of uninitialized analysis in the later stage. >>> >>> I don&

Re: How to traverse all the local variables that declared in the current routine?

pattern depends on “INIT”. Is the above understanding correct? Do I miss anything? More comments and questions are embedded below: > On Dec 3, 2020, at 11:32 AM, Richard Sandiford > wrote: > > Richard Biener via Gcc-patches writes: >> On Tue, Nov 24, 2020 at 4:47 P

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 4, 2020, at 2:50 AM, Richard Biener wrote: > > On Thu, Dec 3, 2020 at 6:33 PM Richard Sandiford > mailto:richard.sandif...@arm.com>> wrote: >> >> Richard Biener via Gcc-patches writes: >>> On Tue, Nov 24, 2020 at 4:47 PM Qing Zhao wrote: &

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 7, 2020, at 1:12 AM, Richard Biener wrote: > > On Fri, Dec 4, 2020 at 5:19 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >> >> On Dec 4, 2020, at 2:50 AM, Richard Biener >> wrote: >> >> On Thu, Dec 3, 202

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 7, 2020, at 11:10 AM, Richard Sandiford > wrote: Another issue is, in order to check whether an auto-variable has initializer, I plan to add a new bit in “decl_common” as: /* In a VAR_DECL, this is DECL_IS_INITIALIZED. */ unsigned decl_is_initialized :1; >>

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 7, 2020, at 12:05 PM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Dec 7, 2020, at 11:10 AM, Richard Sandiford >>> wrote: >>>>>> >>>>>> Another issue is, in order to

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 8, 2020, at 1:40 AM, Richard Biener wrote: > > On Mon, Dec 7, 2020 at 5:20 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >> >> On Dec 7, 2020, at 1:12 AM, Richard Biener >> wrote: >> >> On Fri, Dec 4, 2

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 9, 2020, at 2:23 AM, Richard Biener wrote: > > On Tue, Dec 8, 2020 at 8:54 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >> >> On Dec 8, 2020, at 1:40 AM, Richard Biener > <mailto:richard.guent...@gmail.com>>

Re: How to traverse all the local variables that declared in the current routine?

> On Dec 9, 2020, at 9:12 AM, Richard Biener wrote: > > On Wed, Dec 9, 2020 at 4:04 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >> >> On Dec 9, 2020, at 2:23 AM, Richard Biener >> wrote: >> >> On Tue, Dec 8, 2

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Ping. Richard and Uros, Could you please review the patch and let me know whether it’s Okay for gcc 11? Thanks a lot. Qing > On Oct 6, 2020, at 9:01 AM, Qing Zhao via Gcc-patches > wrote: > > Hi, Gcc team, > > This is the 3rd version of the implementation of patch -fz

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Uros, Thanks a lot for your comments. > On Oct 19, 2020, at 2:30 PM, Uros Bizjak wrote: > >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c >> index f684954..620114f 100644 >> --- a/gcc/config/i386/i386.c >> +++ b/gcc/config/i386/i386.c >> @@ -3551,6 +3551,161 @@ ix86_func

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 20, 2020, at 10:24 AM, Uros Bizjak wrote: > > On Tue, Oct 20, 2020 at 4:01 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> Hi, Uros, >> >> Thanks a lot for your comments. >> >> On Oct 19, 2020, at 2:30 PM, Uros Bizja

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Richard, Thanks a lot for your comments. > On Oct 20, 2020, at 1:12 PM, Richard Sandiford > wrote: > >> >> + >> + if ((strcmp (TREE_STRING_POINTER (id), "skip") != 0) >> + && (strcmp (TREE_STRING_POINTER (id), "used-gpr-arg") != 0) >> + && (strcmp (TREE_STRING_POINTER (id), "used-a

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 21, 2020, at 3:03 AM, Uros Bizjak wrote: > > On Wed, Oct 21, 2020 at 9:18 AM Uros Bizjak <mailto:ubiz...@gmail.com>> wrote: >> >> On Tue, Oct 20, 2020 at 10:04 PM Qing Zhao wrote: >> >>> +/* Check whether the register REGNO should be

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Got it. thanks. Qing > On Oct 21, 2020, at 10:47 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>>> + /* For each of the hard registers, check to see whether we should zero >>>> it if: >>>> + 1. it is a call-used-registers; >&

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 21, 2020, at 11:09 AM, Uros Bizjak wrote: > > On Wed, Oct 21, 2020 at 4:45 PM Qing Zhao wrote: >> >> >> >> -- q -- >> The CPU shall be in x87 mode upon entry to a function. Therefore, >> every function that uses the MMX regis

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Richard, Could you please check the following documentation change, and let me know any suggestions? Thanks. Qing > >> +pass parameters. @samp{used-arg} zeros used call-used registers that >> +pass parameters. @samp{arg} zeros all call-used registers that pass >> +parameters. These 3 choi

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Uros, > On Oct 21, 2020, at 9:45 AM, Qing Zhao via Gcc-patches > wrote: >>>> >> >> Something like this: >> >> --cut here-- >> long double >> __attribute__ ((noinline)) >> test (long double a, long double

Re: [PATCH][middle-end][i386][version 3]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 22, 2020, at 10:34 AM, Uros Bizjak wrote: > > On Thu, Oct 22, 2020 at 4:47 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> Hi, Uros, >> >>> On Oct 21, 2020, at 9:45 AM, Qing Zhao via Gcc-patches >>> wrote: >>

[PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

suggestion; 4. Some minor spelling and style fix. I have tested this new GCC on both x86 and arm64, no regression. Please let me know whether it’s ready for stage 1 gcc11? Thanks. **The changelog: gcc/ChangeLog: 2020-10-24 Qing Zhao H.J.Lu * common.opt: Add new

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

>> >> +/* Generate insns to zero all st/mm registers together. >> + Return true when zeroing instructions are generated. >> + Assume the number of st registers that are zeroed is num_of_st, >> + we will emit the following sequence to zero them together: >> + fldz; \ >

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 26, 2020, at 11:13 AM, Uros Bizjak wrote: > > On Mon, Oct 26, 2020 at 3:45 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >> +/* Generate insns to zero all st/mm registers together. >> + Return true when zeroing instructions

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

sk); else gcc_unreachable (); } return zeroed_hardregs; } > On Oct 26, 2020, at 11:13 AM, Uros Bizjak wrote: > > On Mon, Oct 26, 2020 at 3:45 PM Qing Zhao wrote: >> >> >> +/* Generate insns to zero all st/mm registers together. >> + Retur

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 26, 2020, at 1:42 PM, Uros Bizjak wrote: > > On Mon, Oct 26, 2020 at 6:30 PM Qing Zhao wrote: >> >> >> The following is the current change in i386.c, could you check whether the >> logic is good? > > x87 handling looks good to me. >

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 26, 2020, at 3:33 PM, Uros Bizjak wrote: > > On Mon, Oct 26, 2020 at 9:05 PM Uros Bizjak wrote: >> >> On Mon, Oct 26, 2020 at 8:10 PM Qing Zhao wrote: >>> >>> >>> >>>> On Oct 26, 2020, at 1:42 PM, Uros Bizjak wrote:

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

index 000..7c20b569bfa --- /dev/null +++ b/gcc/testsuite/gcc.target/i386/zero-scratch-regs-30.c @@ -0,0 +1,11 @@ +/* { dg-do compile { target *-*-linux* } } */ +/* { dg-options "-O2 -fzero-call-used-regs=all" } */ +typedef int __v2si __attribute__ ((vector_size (8))); + +_Complex

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 27, 2020, at 3:09 AM, Uros Bizjak wrote: > > On Tue, Oct 27, 2020 at 12:08 AM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> Hi, Uros, >> >> Could you please check the change compared to the previous version for >> i38

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 26, 2020, at 1:47 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi >> index c9f7299..3a884e1 100644 >> --- a/gcc/doc/extend.texi >> +++ b/gcc/doc/extend.texi >> @@ -3992,6 +399

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

scan-assembler "pxor\[ \t\]*%mm1, %mm1" } } */ +/* { dg-final { scan-assembler "movq\[ \t\]*%mm1, %mm2" } } */ +/* { dg-final { scan-assembler-not "movq\[ \t\]*%mm1, %mm3" } } */ +/* { dg-final { scan-assembler-not "movq\[ \t\]*%mm1, %mm4" } } */ +/* { dg-fi

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 27, 2020, at 12:34 PM, Uros Bizjak wrote: > > On Tue, Oct 27, 2020 at 5:10 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> Uros, >> >> The following is the change compared to version 4 after fix all the issues >> you rai

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

till prefer namespace? thanks. Qing > On Oct 27, 2020, at 10:36 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>>> diff --git a/gcc/flag-types.h b/gcc/flag-types.h >>>> index 852ea76..0f7e503 100644 >>>> --- a/gcc/flag-ty

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

Okay, I will change it to namespace. Qing > On Oct 28, 2020, at 9:19 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >> Hi, Richard, >> >> In order to be consistent with other flags in flag-types.h, for example,

Re: [PATCH][middle-end][i386][Version 4] Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all]

es.h:289:1: error: unknown type name ‘namespace’ 289 | namespace zero_regs_code { | ^ Looks like that I should not put this new namespace inside “flag-types.h”? Which other header file I should put this namespace in? thanks. Qing > On Oct 28, 2020, at 9:24 AM, Qing Zhao vi

[PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

ase the program security by either mitigating Return-Oriented Programming (ROP) or preventing information leak through registers. The possible values of CHOICE are the same as for the 'zero_call_used_regs' attribute (*note Function Attributes::). The default is &#x

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 29, 2020, at 6:09 AM, Richard Sandiford > wrote: > > Qing Zhao via Gcc-patches writes: >> +/* Handle a "zero_call_used_regs" attribute; arguments as in >> + struct attribute_spec.handler. */ >> + >> +static tree >> +handle_

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Richard, Now, the documentation (gcc.info) is like following, let me know any issue there: thanks. Qing == 'zero_call_used_regs ("CHOICE")' The 'zero_call_used_regs' attribute causes the compiler to zero a subset of all call-used registers(1) at function return. Th

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 29, 2020, at 1:02 PM, Richard Sandiford > wrote: > > Qing Zhao via Gcc-patches writes: >>>> +Return-Oriented Programming (ROP) or preventing information leak >>> >>> leakage >>> >>> (FWIW, I'm not sure “mitigat

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 29, 2020, at 1:06 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Now, the documentation (gcc.info) is like following, let me know any issue >> there: > > Yeah, looks good apart from merging > >> In order to satisfy users wi

Re: [PATCH][middle-end][i386][version 5]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

Hi, Segher, > On Oct 29, 2020, at 2:31 PM, Segher Boessenkool > wrote: > > On Thu, Oct 29, 2020 at 06:02:58PM +, Richard Sandiford wrote: >> Qing Zhao via Gcc-patches writes: >>>>> +Return-Oriented Programming (ROP) or preventing information leak >>

[PATCH][middle-end][i386][version 6]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

the changes I added compared to the 5th version first, and then the whole patch followed. *The patch compared to 5th version: From 3545cc92b327e11af0dde832a60161da92cc4262 Mon Sep 17 00:00:00 2001 From: qing zhao Date: Thu, 29 Oct 2020 18:40:27 +0100 Subject: [PATCH] fix all issues raised

Re: [PATCH][middle-end][i386][version 6]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

> On Oct 30, 2020, at 4:54 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> @@ -3996,22 +3996,19 @@ with a named @code{target} must be @code{static}. >> @cindex @code{zero_call_used_regs} function attribute >> >> The @code{zero_call_used_regs} a

Re: [PATCH][middle-end][i386][version 6]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all]

FYI. I just committed the patch to gcc11 as: https://gcc.gnu.org/pipermail/gcc-cvs/2020-October/336263.html Qing

[PATCH 2/2] Add a new warning option -Wstrict-flex-arrays.

'-Wstrict-flex-arrays' Warn about inproper usages of flexible array members according to the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to the trailing array field of a structure if it's available, otherwise according to the LEVEL of the option '-fstrict-fl

[PATCH 0/2] Add a new warning option -Wstrict-flex-array

This patch serie include two changes: 1. Change the name of array_at_struct_end_p to array_ref_flexible_size_p. 2. Add a new warning option -Wstrict-flex-arrays and at the same time keep -Warray-bounds unchanged from -fstrict-flex-arrays. The new warning -Wstrict-flex-arrays is implemented a

[PATCH 1/2] Change the name of array_at_struct_end_p to array_ref_flexible_size_p

The name of the utility routine "array_at_struct_end_p" is misleading and should be changed to a new name that more accurately reflects its real meaning. The routine "array_at_struct_end_p" is used to check whether an array reference is to an array whose actual size might be larger than its upper

Re: [PATCH 1/2] Change the name of array_at_struct_end_p to array_ref_flexible_size_p

Thanks. Committed as: https://gcc.gnu.org/pipermail/gcc-cvs/2022-November/373830.html Qing > On Nov 9, 2022, at 2:57 AM, Richard Biener wrote: > > On Tue, 8 Nov 2022, Qing Zhao wrote: > >> The name of the utility routine "array_at_struct_end_p" is misleading >&

Re: [PATCH 2/2] Add a new warning option -Wstrict-flex-arrays.

Ping on this patch. thanks. Qing > On Nov 8, 2022, at 9:51 AM, Qing Zhao wrote: > > '-Wstrict-flex-arrays' > Warn about inproper usages of flexible array members according to > the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to

Ping * 3: Fwd: [V6][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

ension This is basically a C FE and documentation change, I have updated it based on previous comments and suggestions. Joseph, could you review it to see whether this version is ready to go? Thanks a lot. Qing Begin forwarded message: From: Qing Zhao mailto:qing.z...@oracle.com>>

Ping * 3: [V6][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

Hi, Is this patch ready for GCC14? Thanks. Qing Begin forwarded message: From: Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> Subject: Fwd: [V6][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832] Date: April 11, 2023 at 9

Ping * 3: [V6][PATCH 2/2] Update documentation to clarify a GCC extension

Hi, Is this patch ready for GCC14? Thanks. Qing Begin forwarded message: From: Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> Subject: Fwd: [V6][PATCH 2/2] Update documentation to clarify a GCC extension Date: April 11, 2023 at 9:38:29 AM EDT To: Joseph Myers mail

Question on patch -fprofile-partial-training

Hi, Jan, You added the following patch into gcc10: >From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001 From: Jan Hubicka Date: Thu, 5 Dec 2019 19:12:51 +0100 Subject: [PATCH] cgraphclones.c (localize_profile): New function. * cgraphclones.c (localize_profile): New fu

Re: Question on patch -fprofile-partial-training

> On May 4, 2023, at 4:30 AM, Martin Liška wrote: > > On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote: >> Hi, Jan, >> >> You added the following patch into gcc10: >> >> From 34fbe3f0946f88828765184ed6581bda62cdf49f Mon Sep 17 00:00:00 2001 >> F

Re: Question on patch -fprofile-partial-training

> On May 4, 2023, at 9:05 AM, Martin Liška wrote: > > On 5/4/23 14:54, Qing Zhao wrote: >> >> >>> On May 4, 2023, at 4:30 AM, Martin Liška wrote: >>> >>> On 5/3/23 21:10, Qing Zhao via Gcc-patches wrote: >>>> Hi, Jan, >>

Re: [PATCH 2/2] tree-object-size: More consistent behaviour with flex arrays

Hi, Siddhesh, Thanks a lot for this patch, after -fstrict-flex-array functionality has been added into GCC, I think that making the tree-object-size to have consistent behavior with flex arrays is a valuable and natural work that need to be added. I also like the comments you added into tree-

Re: [PATCH 2/2] tree-object-size: More consistent behaviour with flex arrays

> On Jan 26, 2023, at 12:16 PM, Siddhesh Poyarekar wrote: > > On 2023-01-26 11:20, Qing Zhao wrote: >> Hi, Siddhesh, >> Thanks a lot for this patch, after -fstrict-flex-array functionality has >> been added into GCC, >> I think that making the tree-object

[PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

GCC extension accepts the case when a struct with a flexible array member is embedded into another struct (possibly recursively). __builtin_object_size should treat such struct as flexible size per -fstrict-flex-arrays. PR tree-optimization/101832 gcc/ChangeLog: PR tree-optimizat

[PATCH 0/2]PR101832: Handle component_ref to a structure/union field including flexible array member for builtin_object_size

This is the patch for PR101832, to fix builtin_object_size to correctly handle component_ref to a structure/union field that includes a flexible array member. also includes a documentation update for the GCC extension on embedding a structure/union with flexible array member into another structure

[PATCH 2/2] Documentation Update.

Update documentation to clarify a GCC extension on structure with flexible array member being nested in another structure. gcc/ChangeLog: * doc/extend.texi: Document GCC extension on a structure containing a flexible array member to be a member of another structure. --- gcc/doc/e

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

> On Feb 1, 2023, at 6:41 AM, Richard Biener wrote: > > On Tue, 31 Jan 2023, Qing Zhao wrote: > >> GCC extension accepts the case when a struct with a flexible array member >> is embedded into another struct (possibly recursively). >> __builtin_object_size should

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

Siddhesh, Thanks. I will update the testing case per your change. Qing > On Feb 1, 2023, at 11:48 AM, Siddhesh Poyarekar wrote: > > On 2023-01-31 09:11, Qing Zhao wrote: >> GCC extension accepts the case when a struct with a flexible array member >> is embedded into ano

Re: [PATCH 2/2] Documentation Update.

> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar wrote: > > On 2023-01-31 09:11, Qing Zhao wrote: >> Update documentation to clarify a GCC extension on structure with >> flexible array member being nested in another structure. >> gcc/ChangeLog: >>

Re: [PATCH 2/2] Documentation Update.

> On Feb 1, 2023, at 1:57 PM, Siddhesh Poyarekar wrote: > > On 2023-02-01 13:24, Qing Zhao wrote: >>> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar wrote: >>> >>> On 2023-01-31 09:11, Qing Zhao wrote: >>>> Update documentation to clarify

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

> On Feb 2, 2023, at 3:07 AM, Richard Biener wrote: > > On Wed, 1 Feb 2023, Qing Zhao wrote: > >> >> >>> On Feb 1, 2023, at 6:41 AM, Richard Biener wrote: >>> >>> On Tue, 31 Jan 2023, Qing Zhao wrote: >>> >>>> G

Re: [PATCH 2/2] Documentation Update.

> On Feb 2, 2023, at 3:33 AM, Richard Biener wrote: > > On Wed, 1 Feb 2023, Siddhesh Poyarekar wrote: > >> On 2023-02-01 13:24, Qing Zhao wrote: >>> >>> >>>> On Feb 1, 2023, at 11:55 AM, Siddhesh Poyarekar >>>> wrote: &

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

> On Feb 2, 2023, at 8:54 AM, Richard Biener wrote: > > On Thu, 2 Feb 2023, Qing Zhao wrote: > >> >> >>> On Feb 2, 2023, at 3:07 AM, Richard Biener wrote: >>> >>> On Wed, 1 Feb 2023, Qing Zhao wrote: >>> >>

Re: [PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

> On Feb 3, 2023, at 2:49 AM, Richard Biener wrote: > > On Thu, 2 Feb 2023, Qing Zhao wrote: > >> >> >>> On Feb 2, 2023, at 8:54 AM, Richard Biener wrote: >>> >>> On Thu, 2 Feb 2023, Qing Zhao wrote: >>> >>>> &g

<    8   9   10   11   12   13   14   15   >