Re: [V7][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

ote: > > On Fri, 19 May 2023, Qing Zhao via Gcc-patches wrote: > >> +GCC extension accepts a structure containing an ISO C99 @dfn{flexible array > > "The GCC extension" or "A GCC extension". > >> +@item >> +A structure containing a C99 flexib

[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 C99 flexible array member is embedded into another struct or union (possibly recursively) as the last field. __builtin_object_size should treat such struct as flexible size. gcc/c/ChangeLog: PR tree-optimization/101832 * c-decl.c

[PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

on a structure with a C99 flexible array member being nested in another structure. "The GCC extension accepts a structure containing an ISO C99 "flexible array member", or a union containing such a structure (possibly recursively) to be a member of a structure. There are two situations: * A

[V8][PATCH 0/2]Accept and Handle the case when a structure including a FAM nested in another structure

Hi, This is the 8th version of the patch, which rebased on the latest trunk. This is an important patch needed by Linux Kernel security project. compared to the 7th version, the major change are: 1. update the documentation wordings based on Joseph's suggestions. 2. change the name of the new ma

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

> On May 25, 2023, at 1:41 AM, Bernhard Reutner-Fischer > wrote: > > On 24 May 2023 16:09:21 CEST, Qing Zhao wrote: >> Bernhard, >> >> Thanks a lot for your comments. >> >>> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer >>&g

[V8][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 C99 flexible array member is embedded into another struct or union (possibly recursively) as the last field. __builtin_object_size should treat such struct as flexible size. gcc/c/ChangeLog: PR tree-optimization/101832 * c-decl.c

[V8][PATCH 0/2]Accept and Handle the case when a structure including a FAM nested in another structure

(Resend due to the previous patches didn't include the version number) Hi, This is the 8th version of the patch, which rebased on the latest trunk. This is an important patch needed by Linux Kernel security project. compared to the 7th version, the major change are: 1. update the documentation w

[V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

on a structure with a C99 flexible array member being nested in another structure. "The GCC extension accepts a structure containing an ISO C99 "flexible array member", or a union containing such a structure (possibly recursively) to be a member of a structure. There are two situations: * A

[V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

Hi, This patch set introduces a new attribute "element_count" to annotate bounds for C99 flexible array member. A gcc bugzilla PR108896 has been created to record this task: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 A nice writeup "Bounded Flexible Arrays in C" https://people.kernel.

[V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

n_dynamic_object_size and array bound sanitizer to detect out-of-bound errors for flexible array member references. 2023-05-17 Qing Zhao gcc/c-family/ChangeLog: PR C/108896 * c-attribs.cc (handle_element_count_attribute): New function. * c-common.cc (c_flexible_array_mem

[V1][PATCH 2/3] Use the element_count atribute info in builtin object size [PR108896].

2023-05-17 Qing Zhao gcc/ChangeLog: PR C/108896 * tree-object-size.cc (addr_object_size): Use the element_count attribute info. * tree.cc (component_ref_has_element_count_p): New function. (component_ref_get_element_count): New function. * tree.h

[V1][PATCH 3/3] Use the element_count attribute information in bound sanitizer[PR108896]

2023-05-17 Qing Zhao gcc/c-family/ChangeLog: PR C/108896 * c-ubsan.cc (ubsan_instrument_bounds): Use element_count attribute information. gcc/testsuite/ChangeLog: PR C/108896 * gcc.dg/ubsan/flex-array-element-count-bounds.c: New test. --- gcc/c-family

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

> On May 25, 2023, at 4:51 PM, Joseph Myers wrote: > > The documentation in this case is OK, though claims about how a future > version will behave have a poor track record (we tend to end up with such > claims persisting in the documentation even though the change in question > didn't get

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

ESCAPED NONLOCAL index colour1 } same as CALLUSED(69) callarg(71) = { ESCAPED NONLOCAL } callarg(72) = { ESCAPED NONLOCAL } callarg(73) = { ESCAPED NONLOCAL } callarg(74) = { ESCAPED NONLOCAL colour1 } My question: Is it possible to adjust alias analysis to resolve this issue? thanks. Qing

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

2, 2021, 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 DEFER

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 sa

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

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?

> 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

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

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

ue, I will delete the code related to “A” in the next version. There are several places, I put “FIXME” in the comments, 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>>

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

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

not subscribed...) 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!

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

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: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Jul 2021, Qing Zhao wrote: > >> Hi, >> >> This is the 6th version of the patch for the new security feature for GCC. >> >> I have tested it with bootstrap on both x86 and aarch64, regression testing >> on both x86 and aarch64. >> Also compile CPU2017

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

> On Aug 10, 2021, at 2:36 AM, Richard Biener wrote: > > On Mon, 9 Aug 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for you review. >> >> Although these comments are not made on the latest patch (7th version) :-), >> all the

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

Hi, > On Aug 10, 2021, at 9:16 AM, Richard Biener wrote: > > On Tue, 10 Aug 2021, Qing Zhao wrote: > >>>>> >>>>> +static void >>>>> +expand_DEFERRED_INIT (internal_fn, gcall *stmt) >>>>> +{ >>>>> +

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

> On Aug 10, 2021, at 10:22 AM, Richard Biener wrote: > > On Tue, 10 Aug 2021, Qing Zhao wrote: > >> Hi, >> >>> On Aug 10, 2021, at 9:16 AM, Richard Biener wrote: >>> >>> On Tue, 10 Aug 2021, Qing Zhao wrote: >>> >>>

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

Hi, Richard, > On Aug 10, 2021, at 10:22 AM, Richard Biener wrote: >>> >>> Especially in the VLA case but likely also in general (though unlikely >>> since usually the receiver of initializations are simple enough). I'd >>> expect the VLA case end up as >>> >>> *ptr_to_decl = .DEFERRED_INIT (.

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

> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches > wrote: > > Hi, Richard, > >> On Aug 10, 2021, at 10:22 AM, Richard Biener wrote: >>>> >>>> Especially in the VLA case but likely also in general (though unlikely >>>> since

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

> On Aug 11, 2021, at 2:02 AM, Richard Biener wrote: > > On Tue, 10 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> Hi, Richard, >>> >>>>

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

> On Aug 11, 2021, at 4:02 AM, Richard Sandiford > wrote: > > Qing Zhao via Gcc-patches writes: >>> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> Hi, Richard, >>> >>>> On Aug 10, 2021, at

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

> On Aug 11, 2021, at 8:37 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 11, 2021, at 2:02 AM, Richard Biener wrote: >>> >>> On Tue, 10 Aug 2021, Qing Zhao wrote: >>> >>>

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

> On Aug 11, 2021, at 8:58 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 11, 2021, at 8:37 AM, Richard Biener wrote: >>> >>> On Wed, 11 Aug 2021, Qing Zhao wrote: >>> >>

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

.DEFERRED_INIT purpose when the auto var is address taken? If so, “uninitialized analysis” phase need to be further adjusted to specially handle such IR. If not, what should we do when the auto var is address taken? Thanks a lot. Qing > On Aug 11, 2021, at 8:58 AM, Richard Biener wr

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

> On Aug 11, 2021, at 10:53 AM, Richard Biener wrote: > > On August 11, 2021 5:30:40 PM GMT+02:00, Qing Zhao > wrote: >> I modified the routine “gimple_add_init_for_auto_var” as the following: >> >> /* Generate initialization to automatic variable DECL b

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

> On Aug 11, 2021, at 11:15 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Aug 11, 2021, at 4:02 AM, Richard Sandiford >>> wrote: >>>> I came up with the following solution: >>>> >>>> Define the IFN_DEFERRED_I

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

> On Aug 11, 2021, at 11:55 AM, Richard Biener wrote: > > On August 11, 2021 6:22:00 PM GMT+02:00, Qing Zhao > wrote: >> >> >>> On Aug 11, 2021, at 10:53 AM, Richard Biener wrote: >>> >>> On August 11, 2021 5:30:40 PM GMT+02:00,

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

Any comments and suggestions on this issue? Qing j > On Aug 11, 2021, at 11:55 AM, Richard Biener wrote: > > On August 11, 2021 6:22:00 PM GMT+02:00, Qing Zhao > wrote: >> >> >>> On Aug 11, 2021, at 10:53 AM, Richard Biener wrote: >>> >>>

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

s not need any change. Everything works well. And I believe that treating “call to .DEFERRED_INIT” as “is_gimple_val” is reasonable since this call actually is a constant. Let me know if you have any objection on this solution. thanks. Qing > On Aug 11, 2021, at 3:30 PM, Qing Zhao via Gcc-pa

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

Thanks a lot for the help. Qing > On Aug 9, 2021, at 9:09 AM, Richard Biener wrote: > > On Tue, 27 Jul 2021, Qing Zhao wrote: > > +created during gimplification phase. Refer to gimplify_vla_decl > +for details. */ > + tree var_decl = (TREE_CODE (var

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

al_bytes; i++) CONSTRUCTOR_APPEND_ELT (elts, NULL_TREE, element); pattern = build_constructor (array_type, elts); pattern = build1 (VIEW_CONVERT_EXPR, var_type, pattern); } } Thanks. Qing On Aug 12, 2021, at 2:24 PM, Qing Zhao via Gcc

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

> On Aug 16, 2021, at 2:12 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> Hi, >> >> I finally decided to take another approach to resolve this issue, it >> resolved all the potential issues with the “address taken” auto variabl

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

> On Aug 16, 2021, at 10:08 AM, Richard Biener wrote: > > On August 16, 2021 4:48:16 PM GMT+02:00, Qing Zhao > wrote: >> >> >>> On Aug 16, 2021, at 2:12 AM, Richard Biener wrote: >>> >>> On Wed, 11 Aug 2021, Qing Zhao wrote: >>

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

> On Aug 16, 2021, at 2:40 AM, Richard Biener wrote: > > On Thu, 12 Aug 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> For RTL expansion of call to .DEFERRED_INIT, I changed my code per your >> suggestions like following: >> >> ==

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

> On Aug 16, 2021, at 2:11 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> Hi, >> >> I met another issue for “address taken” auto variable, see below for details: >> >> the testing case: (gcc/testsuite/gcc.dg/unini

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

> On Aug 16, 2021, at 2:40 AM, Richard Biener wrote: > > On Thu, 12 Aug 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> For RTL expansion of call to .DEFERRED_INIT, I changed my code per your >> suggestions like following: >> >> ==

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

> On Aug 17, 2021, at 3:43 AM, Richard Biener wrote: > > On Mon, 16 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 16, 2021, at 2:40 AM, Richard Biener wrote: >>> >>> On Thu, 12 Aug 2021, Qing Zhao wrote: >>> >>>>

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

> On Aug 17, 2021, at 3:29 AM, Richard Biener wrote: > > On Mon, 16 Aug 2021, Qing Zhao wrote: > >> My current code for expand_DEFERRED_INIT is like the following, could you >> check and see whether there is any issue for it: >> >> #define INI

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

> On Aug 17, 2021, at 9:45 AM, Richard Biener wrote: > > On Tue, 17 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 17, 2021, at 3:43 AM, Richard Biener wrote: >>> >>> On Mon, 16 Aug 2021, Qing Zhao wrote: >>> >>

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

> On Aug 16, 2021, at 11:48 AM, Qing Zhao via Gcc-patches > wrote: > >>> From the above IR file after “FRE”, we can see that the major issue with >>> this IR is: >>> >>> The address taken auto variable “alt_reloc” has been completely replac

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

> On Aug 17, 2021, at 9:50 AM, Qing Zhao via Gcc-patches > wrote: > > > >> On Aug 17, 2021, at 3:29 AM, Richard Biener wrote: >> >> On Mon, 16 Aug 2021, Qing Zhao wrote: >> >>> My current code for expand_DEFERRED_INIT is like the followin

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

> On Aug 17, 2021, at 10:04 AM, Qing Zhao via Gcc-patches > wrote: > > > >> On Aug 16, 2021, at 11:48 AM, Qing Zhao via Gcc-patches >> wrote: >> >>>> From the above IR file after “FRE”, we can see that the major issue with >>>&g

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

> On Aug 18, 2021, at 2:19 AM, Richard Biener wrote: > > On Tue, 17 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 17, 2021, at 10:04 AM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> >>> >>>> On Aug 16,

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

> On Aug 18, 2021, at 2:15 AM, Richard Biener wrote: > > On Tue, 17 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 17, 2021, at 9:50 AM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> >>> >>>> On Aug 17, 2

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

> On Aug 19, 2021, at 4:00 AM, Richard Biener wrote: > > On Wed, 18 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 18, 2021, at 2:15 AM, Richard Biener wrote: >>> >>> On Tue, 17 Aug 2021, Qing Zhao wrote: >>> >>>

[Patch][doc][PR101843]clarification on building gcc and binutils together

rom 9bf6f9a5964df26cac32d90f57719f4871874d54 Mon Sep 17 00:00:00 2001 From: qing zhao Date: Thu, 19 Aug 2021 18:20:49 -0400 Subject: [PATCH] doc/install.texi: add a generic advice on building gcc and binutils together. gcc/ChangeLog: * doc/install.texi: Add a generic advice on building gcc and binutils together. --- gcc/doc/install.t

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

> On Aug 19, 2021, at 8:54 AM, Qing Zhao via Gcc-patches > wrote: > >>>>> Breakpoint 1, expand_DEFERRED_INIT (stmt=0x7fffe96ae348) at >>>>> ../../latest-gcc/gcc/internal-fn.c:3021 >>>>> 3021mark_addressable (lhs); >>&g

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 11, 2020, at 3:36 PM, Segher Boessenkool > wrote: > > On Fri, Sep 11, 2020 at 03:17:19PM -0500, Qing Zhao wrote: >>> On Sep 11, 2020, at 3:05 PM, Segher Boessenkool >>> wrote: >>> On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote: >

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 11, 2020, at 4:03 PM, Segher Boessenkool > wrote: > > Hi! > > On Fri, Sep 11, 2020 at 03:14:57PM -0500, Qing Zhao wrote: >> My understanding of how this scheme helps ROP is: the attacker usually uses >> scratch register to pass > > Help obs

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 11, 2020, at 4:44 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Sep 11, 2020, at 12:32 PM, Richard Sandiford >>> >> If we go for (2), then I think it would be better to do >>> it at the start of pass_late_compilation i

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 11, 2020, at 4:51 PM, Segher Boessenkool > wrote: > > On Fri, Sep 11, 2020 at 04:29:16PM -0500, Qing Zhao wrote: >>> On Sep 11, 2020, at 4:03 PM, Segher Boessenkool >>> wrote: >>>> The parameters that are passed to sys call will be d

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Richard, > On Sep 11, 2020, at 5:56 PM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 11, 2020, at 4:44 PM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: >>>>> On

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 14, 2020, at 11:33 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> Like I mentioned earlier though, passes that run after >>> pass_thread_prologue_and_epilogue can use call-clobbered registers that >>> weren't previously used.

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 14, 2020, at 2:20 PM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 14, 2020, at 11:33 AM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: >&g

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 14, 2020, at 6:09 PM, Segher Boessenkool > wrote: > > On Fri, Sep 11, 2020 at 05:41:47PM -0500, Qing Zhao wrote: >>> On Sep 11, 2020, at 4:51 PM, Segher Boessenkool >>> wrote: >>> It is definitely *not* effective if there are gadgets that se

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 15, 2020, at 4:11 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 14, 2020, at 2:20 PM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao mailto:qing.z...@oracle.com>> w

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 15, 2020, at 2:41 PM, Segher Boessenkool > wrote: > > On Tue, Sep 15, 2020 at 10:11:41AM +0100, Richard Sandiford wrote: >> Qing Zhao writes: >>>> On Sep 14, 2020, at 2:20 PM, Richard Sandiford >>>> wrote: > (Putting correct info

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 15, 2020, at 6:09 PM, Segher Boessenkool > wrote: > > On Tue, Sep 15, 2020 at 05:31:48PM -0500, Qing Zhao wrote: >>> But, scheduling runs *after* that, and then you need to prevent the >>> inserted (zeroing) insns from moving -- if you don't, the

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

. X86 backend will implement a special version for “gen_zero_call_used_regs”, and “pro_epilogue_use”. Let me know if you have any more comment on this approach. thanks. Qing > On Sep 16, 2020, at 5:35 AM, Segher Boessenkool > wrote: > > On Tue, Sep 15, 2020 at 08:51:57PM -050

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 17, 2020, at 1:17 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Segher and Richard, >> >> Now there are two major concerns from the discussion so far: >> >> 1. (From Richard): Inserting zero insns should be done after >&g

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 17, 2020, at 11:27 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 17, 2020, at 1:17 AM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: >>>> Segher and Richard

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Richard, During my implementation of the new version of the patch. I still feel that it’s not practical to add a default definition in the middle end to just use move patterns to zero each selected register. The major issues are: There are some target specific information on how to define

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 18, 2020, at 5:51 PM, Segher Boessenkool > wrote: > > Hi! > > On Fri, Sep 18, 2020 at 03:31:12PM -0500, Qing Zhao wrote: >> Let me know your opinion: >> >> A. Will not provide default definition in middle end to generate the >> zero

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 21, 2020, at 2:23 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >> Hi, Richard, >> >> During my implementation of the new version of the patch. I still feel that >> it’s not practical to add a defaul

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 21, 2020, at 10:35 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> My major concern with the default implementation of the hook is: >> >> If a target has some special registers that should not be zeroed, and we do >> not provide a

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 21, 2020, at 2:11 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> But in cases where there is no underlying concept that can sensibly >>> be extracted out, it's OK if targets need to override the default >>> to get correct be

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches > wrote: > > > >> On Sep 21, 2020, at 2:11 PM, Richard Sandiford >> wrote: >> >> Qing Zhao writes: >>>> But in cases where there is no underlying concept that can sensibl

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 21, 2020, at 3:34 PM, Segher Boessenkool > wrote: > > On Mon, Sep 21, 2020 at 09:13:58AM -0500, Qing Zhao wrote: >>> On Sep 18, 2020, at 5:51 PM, Segher Boessenkool >>> wrote: >>>> B. Will provide a default definition in middle end to ge

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Hongjiu, > On Sep 22, 2020, at 11:31 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Sep 21, 2020, at 2:22 PM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> >>> >>>> On Sep 21, 2020, at 2:11 PM, Richar

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 22, 2020, at 1:35 PM, H.J. Lu wrote: > > On Tue, Sep 22, 2020 at 11:25 AM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> Hi, Hongjiu, >> >> >>> On Sep 22, 2020, at 11:31 AM, Richard Sandiford >>> wrote: >>

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 22, 2020, at 12:06 PM, Richard Sandiford > wrote: The following is what I see from i386.md: (I didn’t look at how “UNSPEC_volatile” is used in data flow analysis in GCC yet) ;; UNSPEC_VOLATILE is considered to use and clobber all hard registers and ;;

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 23, 2020, at 5:43 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Sep 22, 2020, at 1:35 PM, H.J. Lu wrote: >>> On Tue, Sep 22, 2020 at 11:25 AM Qing Zhao >> <mailto:qing.z...@oracle.com>> wrote: >>>>> O

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 23, 2020, at 6:05 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 22, 2020, at 12:06 PM, Richard Sandiford >>> wrote: >>>>>> >>>>>> The following is what I see

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 22, 2020, at 5:37 PM, Segher Boessenkool > wrote: > > Hi! > > On Tue, Sep 22, 2020 at 06:06:30PM +0100, Richard Sandiford wrote: >> Qing Zhao writes: >>> Okay, thanks for the info. >>> then, what’s the current definition of UNSPEC_VOLATI

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 23, 2020, at 9:22 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 23, 2020, at 5:43 AM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: >>>>> On Sep 22, 202

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 23, 2020, at 9:32 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Sep 23, 2020, at 6:05 AM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao mailto:qing.z...@oracle.com>> writes: >>>&

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 23, 2020, at 9:40 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>>>> Dropping them is fine with me FWIW. That seems like a natural use >>>>> for the new hook: drop zeroing that isn't actively wrong, but isn't >>>

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 23, 2020, at 10:21 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 23, 2020, at 9:32 AM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: >>>>> On Sep 23,

One issue with default implementation of zero_call_used_regs

Hi, Richard, As you suggested, I added a default implementation of the target hook “zero_cal_used_regs (HARD_REG_SET)” as following in my latest patch /* The default hook for TARGET_ZERO_CALL_USED_REGS. */ void default_zero_call_used_regs (HARD_REG_SET need_zeroed_hardregs) { gcc_assert (!h

Re: One issue with default implementation of zero_call_used_regs

> On Sep 25, 2020, at 7:53 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Hi, Richard, >> >> As you suggested, I added a default implementation of the target hook >> “zero_cal_used_regs (HARD_REG_SET)” as following in my latest patc

Re: One issue with default implementation of zero_call_used_regs

> On Sep 25, 2020, at 10:28 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >>> On Sep 25, 2020, at 7:53 AM, Richard Sandiford >>> wrote: >>> >>> Qing Zhao writes: >>>> Hi, Richard, &g

Re: One issue with default implementation of zero_call_used_regs

> On Sep 25, 2020, at 11:58 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>>> >>>> >>>> Which data structure in GCC should be used here to hold this returned >>>> value as Set of RTX ? >>> >>> A HARD

Re: One issue with default implementation of zero_call_used_regs

> On Sep 25, 2020, at 12:31 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Last question, in the following code portion: >> >> /* Now we get a hard register set that need to be zeroed, pass it to >> target to generate zeroing sequence.

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

> On Sep 25, 2020, at 9:55 AM, Martin Liška wrote: > > PING^5 > Thanks a lot for ping this patch again. Hopefully it can be committed into GCC 11 very soon. Qing > On 7/21/20 6:24 PM, Qing Zhao wrote: >> PING^4. >> Our company is waiting for this patch

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

Hi, Richard, At the same time testing aarch64, I also tested the default implementation on rs6000 target. The default implementation now is: +/* The default hook for TARGET_ZERO_CALL_USED_REGS. */ + +HARD_REG_SET +default_zero_call_used_regs (HARD_REG_SET need_zeroed_hardregs) +{ + gcc_asser

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

> On Sep 30, 2020, at 4:21 AM, Richard Sandiford > wrote: > > Qing Zhao mailto:qing.z...@oracle.com>> writes: >> Hi, Richard, >> >> At the same time testing aarch64, I also tested the default implementation >> on rs6000 target. >> >

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

> On Sep 30, 2020, at 11:25 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>>> >>>> As I checked, when the FP registers are zeroed, the above failure happened. >>>> >>>> I suspect that the issue still relate to the foll

<    4   5   6   7   8   9   10   11   12   13   >