Re: HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument?

On Jun 30, 2021, at 2:46 AM, Richard Biener mailto:rguent...@suse.de>> wrote: On Wed, 30 Jun 2021, Qing Zhao wrote: Hi, I am testing the 4th patch of -ftrivial-auto-var-init with CPU2017 today, and found the following issues: In the dump file of “*t.i.031t.objsz1”, w

HELP!! How to inhibit optimizations applied to .DEFERRED_INIT argument?

Hi, I am testing the 4th patch of -ftrivial-auto-var-init with CPU2017 today, and found the following issues: In the dump file of “*t.i.031t.objsz1”, we have: : __s1_len_217 = .DEFERRED_INIT (__s1_len_176, 2); __s2_len_218 = .DEFERRED_INIT (__s2_len_177, 2); __s2_len_219 = 7; if

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

22, 2021 at 09:25:57AM +0100, Richard Sandiford wrote: >>> Kees Cook writes: >>>> On Mon, Jun 21, 2021 at 03:39:45PM +, Qing Zhao wrote: >>>>> So, if “pattern value” is “0x”, then it’s a valid >>>>> canonical virtual memo

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Jun 22, 2021, at 9:15 AM, Richard Biener wrote: > > On Tue, 22 Jun 2021, Qing Zhao wrote: > >> >> >>> On Jun 22, 2021, at 9:00 AM, Richard Biener wrote: >>> >>> On Tue, 22 Jun 2021, Qing Zhao wrote: >>> >>

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Jun 22, 2021, at 9:00 AM, Richard Biener wrote: > > On Tue, 22 Jun 2021, Qing Zhao wrote: > >> So, I am wondering why not still keep my current implementation on >> assign different patterns for different types? >> >> This major issue with this

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

ichard Sandiford wrote: Kees Cook mailto:keesc...@chromium.org>> writes: On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote: So, if “pattern value” is “0x”, then it’s a valid canonical virtual memory address. However, for most OS, “0x” should be not i

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Jun 21, 2021, at 11:18 AM, Kees Cook wrote: > > On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote: >> So, if “pattern value” is “0x”, then it’s a valid canonical >> virtual memory address. However, for most OS, “0x” should &g

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Jun 21, 2021, at 10:35 AM, Richard Biener wrote: >>> I think we can drop -fauto-var-init=pattern and just go with block >>> initializing which will cover padding as well which means we can >>> stay with the odd -ftrivial-auto-var-init name used by CLANG and >>> add no additional options.

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Kees, On Jun 18, 2021, at 6:47 PM, Kees cook mailto:keesc...@chromium.org>> wrote: On Wed, Jun 16, 2021 at 07:39:02PM +, Qing Zhao wrote: So, the major question now is: Is one single repeatable pattern enough for pattern initialization for all different types of auto var

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

HI, Richard, > On Jun 21, 2021, at 2:53 AM, Richard Biener wrote: > >> >> >> This is for the compatibility with CLANG. -:). >> (https://reviews.llvm.org/D54604) > > I don't care about functional 1:1 "compatibility" with CLANG. Okay. -:) > >> 1. Pattern initialization >> >> This is the

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

So, the major question now is: Is one single repeatable pattern enough for pattern initialization for all different types of auto variables? If YES, then the implementation for pattern initialization will be much easier and simpler as you pointed out. And will save me a lot of pain to

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, On Jun 16, 2021, at 1:19 AM, Richard Biener mailto:rguent...@suse.de>> wrote: +/* Expand the IFN_DEFERRED_INIT function according to its second argument. */ +static void +expand_DEFERRED_INIT (internal_fn, gcall *stmt) +{ + tree var = gimple_call_lhs (stmt); + tree init =

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, > On Jun 15, 2021, at 8:21 AM, Richard Biener wrote: >> >> >> +/* Expand the IFN_DEFERRED_INIT function according to its second >> argument. */ >> +static void >> +expand_DEFERRED_INIT (internal_fn, gcall *stmt) >> +{ >> + tree var = gimple_call_lhs (stmt); >> + tree init =

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard: On Jun 11, 2021, at 10:49 AM, Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> wrote: On May 26, 2021, at 6:18 AM, Richard Biener mailto:rguent...@suse.de>> wrote: +/* Expand the IFN_DEFERRED_INIT function according to its second argument. */

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Jun 11, 2021, at 10:49 AM, Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> wrote: On Jun 11, 2021, at 6:12 AM, Richard Biener mailto:rguent...@suse.de>> wrote: On Thu, 10 Jun 2021, Qing Zhao wrote: Hi, Richard, I need more discussion on the following comment

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Jun 11, 2021, at 6:12 AM, Richard Biener wrote: > > On Thu, 10 Jun 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> I need more discussion on the following comments you raised: >> >>> On May 26, 2021, at 6:18 AM, Richard Biener wrote: >&

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, I need more discussion on the following comments you raised: > On May 26, 2021, at 6:18 AM, Richard Biener wrote: > > +/* Expand the IFN_DEFERRED_INIT function according to its second > argument. */ > +static void > +expand_DEFERRED_INIT (internal_fn, gcall *stmt) > +{ > + tree

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Jun 8, 2021, at 11:59 AM, Kees Cook wrote: > > On Tue, Jun 08, 2021 at 09:41:38AM +0200, Richard Biener wrote: >> On Mon, 7 Jun 2021, Qing Zhao wrote: >>> >>> Personally, I am okay with splitting padding initialization from this >>> cu

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

, Richard Biener wrote: >> On Mon, 7 Jun 2021, Qing Zhao wrote: >>> On Jun 7, 2021, at 2:48 AM, Richard Biener >>> mailto:rguent...@suse.de>> wrote: >>> >>> Meh - can you try using a mailer that does proper quoting? It's difficult >>> to s

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

On Jun 8, 2021, at 2:41 AM, Richard Biener mailto:rguent...@suse.de>> wrote: Which is also why I suggested to split out the padding initialization bits to a separate patch (and option). Personally, I am okay with splitting padding initialization from this current patch, Kees, what’s your

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, > On Jun 7, 2021, at 2:53 AM, Richard Biener wrote: > >> >> To address the above suggestion: >> >> My study shows: the call to __builtin_clear_padding is expanded during >> gimplification phase. >> And there is no __bultin_clear_padding expanding during rtx expanding phase. >> However,

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

(Kees, can you answer one of Richard’s question below? On the reason to initialize padding of structures) Richard, On Jun 7, 2021, at 2:48 AM, Richard Biener mailto:rguent...@suse.de>> wrote: Meh - can you try using a mailer that does proper quoting? It's difficult to spot your added

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, On May 26, 2021, at 6:18 AM, Richard Biener mailto:rguent...@suse.de>> wrote: On Wed, 12 May 2021, Qing Zhao wrote: Hi, This is the 3rd version of the patch for the new security feature for GCC. Please take look and let me know your comments and suggestions. +/* Return

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, For the following, I need more clarification: +/* Expand the IFN_DEFERRED_INIT function according to its second argument. */ +static void +expand_DEFERRED_INIT (internal_fn, gcall *stmt) +{ + tree var = gimple_call_lhs (stmt); + tree init = NULL_TREE; + enum auto_init_type

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

(Resend, the previous version messed up your questions and my answers, hopefully this time it’s better) Hi, Richard, Thanks a lot for your comments. On May 26, 2021, at 6:18 AM, Richard Biener mailto:rguent...@suse.de>> wrote: On Wed, 12 May 2021, Qing Zhao wrote: Hi, This is t

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, Thanks a lot for your comments. On May 26, 2021, at 6:18 AM, Richard Biener mailto:rguent...@suse.de>> wrote: On Wed, 12 May 2021, Qing Zhao wrote: Hi, This is the 3rd version of the patch for the new security feature for GCC. Please take look and let me know your co

Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Ping…. Qing On May 12, 2021, at 12:16 PM, Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> wrote: Hi, This is the 3rd version of the patch for the new security feature for GCC. Please take look and let me know your comments and suggestions. thanks. Qing **C

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,

<    4   5   6   7   8   9   10   11   12   >