Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> >> >>> @@ -11950,6 +12088,72 @@ lower_bound_in_type (tree outer, tree inner) >>>} >>> } >>> >>> +/* Returns true when the given TYPE has padding inside it. >>> + return false otherwise. */ >>> +bool >>> +type_has_padding (tree type) >> >> Would it be possible to reuse

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, During the change for the 2nd version based on your previous comments, I have the following questions need your help: > >> + sra_stats.subtree_deferred_init++; >> +} >> + else if (access->grp_to_be_debug_replaced) >> +{ >> + /* FIXME, this part might have

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Apr 27, 2021, at 1:30 AM, Richard Biener wrote: > >> >> equivalent in all respects. And if we were trying to make them >> equivalent, we'd need to do much more than this. >> >> The same applies to the pattern case. If “x” is initialised to a pattern >> that happens to point to a real

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Apr 26, 2021, at 12:47 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >>>> @@ -1831,6 +2000,17 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p) >>>> as they may contain a label address. */ >>>>

Question on __gcov_indirect_call

Hi, We met the following linking error when building our important application: > …./ld: .o(.text.startup+0x13): unresolvable R_X86_64_TPOFF32 relocation > against symbol `__gcov_indirect_call’ Looks like that current “__gcov_indirect_call”’s TLS_MODEL is local exec. If recompiling

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

the testsuite > parts in the interests of time. I'll probably have more comments in > future rounds, just wanted to get the ball rolling. > > This is realy Richi's area more than mine though, so please take this > with a grain of salt. > > Qing Zhao writes: >> 2. initialize a

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Kees, Thanks a lot for your testing on the linux kernel, I am so happy that this time it works well. > On Apr 7, 2021, at 5:19 PM, Kees Cook wrote: > > On Wed, Mar 24, 2021 at 04:21:49PM -0500, Qing Zhao wrote: >> This is the 2nd version of the patch for the new security

Re: [patch for gcc12 stage1][version 2] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Ping > On Mar 24, 2021, at 4:21 PM, Qing Zhao via Gcc-patches > wrote: > > Hi, > > This is the 2nd version of the patch for the new security feature for GCC. > > Could you please take a look at it and let me know any comments and issues. > > Thanks. > >

Re: [PATCH] testsuite: Disable zero-scratch-regs-{8, 9, 10, 11}.c on s390* [PR97680]

Yes, basically, I agreed with Eric. One of the major reason to intentionally put these testing cases under c-c++-common is to fail them by default on the platforms that do not support this feature yet. Then the platform maintainer could decide whether to complete this feature on the

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

(CC’ing gcc-patch alias). Hi, Kees, > On Mar 12, 2021, at 3:55 PM, Kees Cook wrote: > > On Fri, Mar 12, 2021 at 03:35:28PM -0600, Qing Zhao wrote: >> Hi, Kees, >> >> I am looking at the structure padding initialization issue. And also have >> some quest

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Kees, I am looking at the structure padding initialization issue. And also have some questions: > On Feb 24, 2021, at 10:41 PM, Kees Cook wrote: > > It looks like there is still some issues with padding and pre-case > switch variables. Here's the test output, FWIW: > > >

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Mar 11, 2021, at 6:46 PM, Kees Cook wrote: > > On Thu, Mar 11, 2021 at 03:47:17PM -0600, Qing Zhao wrote: >> Hi, Kees, >> >> Sorry for the late reply (I have been busy with other work recently). >> >> Currently, I am working on the issue of flex

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

ote: > > On Thu, Feb 25, 2021 at 05:56:38PM -0600, Qing Zhao wrote: >> Just noticed that you didn’t add -fauto-var-init-approach=D to the command >> line. > > Ah-ha! I didn't realize that was needed; thanks. However, now some of the > sources crash in a different way. Her

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

and also -ftrivial-auto-var-init=pattern -fauto-var-init-approach=D on cpu2017, without any issue). Thanks a lot for your help. Qing On Feb 26, 2021, at 3:42 PM, Kees Cook wrote: > > On Thu, Feb 25, 2021 at 05:56:38PM -0600, Qing Zhao wrote: >> Just noticed that you didn’t add -fa

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

. Sorry for the confusion. > On Feb 25, 2021, at 2:00 PM, Kees Cook wrote: > > On Thu, Feb 25, 2021 at 12:15:01PM -0600, Qing Zhao wrote: >>> On Feb 24, 2021, at 10:41 PM, Kees Cook wrote: >>> [...] >>> test_stackinit: trailing_hole_none ok >>> test

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

ubscribed...) Yes, I will. > > On Thu Feb 18, 2021 Qing Zhao said: >> Initialize automatic variables with new first class option >> -ftrivial-auto-var-init=[uninitialized|pattern|zero] > > Yay! I'm really excited to see this. Thank you for working on > it! I've built

Re: PR 96391? Can we fix it for gcc11?

Hi, Richard, > On Feb 9, 2021, at 11:36 AM, Richard Biener wrote: > > On Tue, 9 Feb 2021, Qing Zhao wrote: >> >> Yes, I understand that without a working testing case to repeat the error, >> it’s very hard to debug and fix the issue. >> >> However

[RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

, please review those part and let me know any issues with those parts. ***Changelog: gcc/ChangeLog: 2021-02-17 qing zhao mailto:qing.z...@oracle.com>> * common.opt (ftrivial-auto-var-init=): New. (fauto-var-init-approach=): Likewise. * doc/extend.texi: Do

Re: [PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

Hello, What’s the status of this patch now? Is there any major technical issue with the patch? Our company has been waiting for this patch for almost one year, we need it for our important application. Could this one be approved and committed to gcc11? Thanks. Qing > On Feb 5, 2021, at

Re: PR 96391? Can we fix it for gcc11?

> On Feb 9, 2021, at 11:36 AM, Richard Biener wrote: > > On Tue, 9 Feb 2021, Qing Zhao wrote: > >> Richard, >> >> Thank you for the reply. >> >> Yes, I understand that without a working testing case to repeat the error, >> it’s very

Testing case for fix-point type auto variables?

Hi, I am trying to add testing cases for verifing pattern initialization or zero initialization to fix-point type auto variables. Please let me know where in the test suite directory I can find a good example for fix-point type programming? Thanks. Qing

Re: PR 96391? Can we fix it for gcc11?

building engineer to see what we can do. Or, I will try to debug and fix this issue myself… Qing > On Feb 9, 2021, at 2:18 AM, Richard Biener wrote: > > On Mon, 8 Feb 2021, Qing Zhao wrote: > >> Hi, >> >> The bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 &g

PR 96391? Can we fix it for gcc11?

Hi, The bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 Bug 96391 - [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359 has been opened on 7/30/2020, and multiple users reported the

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

at 9:17 AM, Qing Zhao via Gcc-patches wrote: > > > >> On Feb 2, 2021, at 1:43 AM, Richard Biener wrote: >> >> On Mon, 1 Feb 2021, Qing Zhao wrote: >> >>> Hi, Richard, >>> >>> I have adjusted SRA phase to split calls to DEFERRED_

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

> On Feb 2, 2021, at 1:43 AM, Richard Biener wrote: > > On Mon, 1 Feb 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion. >> >> And now the routine “bump_map” in 511.povra

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

le to adjust alias analysis to resolve this issue? thanks. Qing > On Jan 18, 2021, at 10:12 AM, Qing Zhao via Gcc-patches > wrote: > >>>>> I checked the routine “poverties::bump_map” in 511.povray_r since it >>>>> has a lot stack increase >

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

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 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 &g

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

> 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

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: &

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

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

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

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: 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 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 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

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 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 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?

or 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 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?

> 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: [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 r

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: 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 l

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

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.

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?

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

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

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

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

with --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

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

> On Nov 16, 2020, at 4:29 AM, Martin Liška wrote: > > On 11/10/20 9:53 PM, Qing Zhao wrote: >> The deadline for gcc11 stage 1 is approaching. The pinged patch is one that >> has been sent for review 8 months ago in order to >> Make into gcc11. > > Hello.

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

Jakub and Jeff, PING^7 on the following patch proposed 8 months ago for gcc11: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542198.html The deadline for gcc11 stage 1 is approaching. The pinged patch is one that has

[Patch][i386][PR97715]: Fix a bug when adding -fzero-call-used-regs=all with -mno-80387

2001 From: qing zhao Date: Wed, 4 Nov 2020 20:46:15 +0100 Subject: [PATCH] i386: Fix PR97715 This change fixes a bug in the i386 backend when adding -fzero-call-used-regs=all on a target that has no x87 registers. When there is no x87 registers available, we should not zero stack registers. gcc

Re: Testsuite fails on PowerPC with: 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 Nov 4, 2020, at 1:00 PM, Segher Boessenkool > wrote: > > On Wed, Nov 04, 2020 at 01:20:58PM +, Richard Sandiford wrote: >> Tobias Burnus writes: >>> Three of the testcases fail on PowerPC: >>> gcc.target/i386/zero-scratch-regs-{9,10,11}.c >>>

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

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

[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 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 >>

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]

> 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 “mitigating R

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.

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_

[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 Attributes::). The default is 'skip'. You can control this behavior for a specific function by using the function attribute 'zero_call_used_regs' (*note Function Attributes::). **The changelog: gcc/ChangeLog: 2020-10-28 Qing Zhao H.J.Lu * commo

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]

: 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 via Gcc-patc

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]

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]

> 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

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]

t;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-final { scan-assembler

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]

> 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 >&g

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]

69bfa --- /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 long double ret_x87_cplx

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]

> 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]

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. >> + Return true when

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 instructio

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; \

[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 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: >>

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]

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

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]

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-regi

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

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

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]

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 @@

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

[patch][DOC]PR97309--improve documentation of -fallow-store-data-races

Richard, On behalf of John Henning, I am sending the following simple documentation patch for an official approval. Hopefully this patch can get into gcc11. Per John, the wording of the documentation change was based on the discussion between him and you on 25-Aug-2020. I created a gcc

[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]

to generate the instruction sequnce that zero the regs. C. Data flow maintenance. 4.Use "lookup_attribute" to get the attribute information instead of setting the attribute information into "tree_decl_with_vis" in tree-core.h. **The changelog: gcc/ChangeLog: 2020-

Re: Another issue on RS6000 target. Re: One issue with default implementation of zero_call_used_regs

> On Oct 1, 2020, at 11:20 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Hi, Richard, >> >> To answer the question, which registers should be included in “ALL”. >> I studied X86 hard register set in more details. And also

Re: Another issue on RS6000 target. Re: One issue with default implementation of zero_call_used_regs

> On Oct 2, 2020, at 10:15 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> >>> Going back to the default hook, I guess one option is: >>> >>> rtx zero = CONST0_RTX (reg_raw_mode[regno]); >>> rtx_insn *

Re: Another issue on RS6000 target. Re: One issue with default implementation of zero_call_used_regs

> > Going back to the default hook, I guess one option is: > > rtx zero = CONST0_RTX (reg_raw_mode[regno]); > rtx_insn *insn = emit_insn (gen_rtx_SET (regno_reg_rtx[regno], zero)); > if (!valid_insn_p (insn)) > sorry (…); “Sorry” here will tell the user that the implementation on

<    4   5   6   7   8   9   10   11   12   >