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

erything 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. > > Yeah, I object to this solution. Can you explai

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

> >>> Yeah, I object to this solution. >> >> Can you explain what’s the major issue for this solution? > > It punches a hole into the GIMPLE IL which is very likely incomplete and will > cause issues elsewhere. In particular the corresponding type check is

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: >> >> == >> #define INIT_PATTERN_VALUE 0xFE >> s

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

;> We got the following: >>>>>> >>>>>> _1 = .DEFERRED_INIT (4, 2, 0); >>>>>> alt_reloc = _1; >>>>>> >>>>>> I guess the temp “_1” is created because “alt_reloc” is address taken. >>>>> >>>>

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: >> >> == >> #define INIT_PATTERN_VALUE 0xFE >> s

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: >>> Hi, Richard, For RTL expansion of call to .DEFERRED_INIT, I chang

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 INIT_PATTERN_VALUE 0xFE >> static void >> expand_DE

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: >>> > On Aug 16, 2021, at 2:40 AM, Richard Biener 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

Hi, This patch is on behalf of John Henning, who opened PR 101843: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101843 He proposed the following doc change, please take a look and let me know whether this is Okay for commit? Thanks. Qing >From 9bf6f9a5964df26cac32d90f57719f4871874d54

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: > On Sep 11, 2020, at 12:13 PM, Segher

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 obstruct ROP ;-) Thanks for catching my mis

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 instead. (Some targets wouldn't >>> cope with do

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 destroyed, therefore, the attack will likely

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 Sep 11, 2020, at 12:32 PM, Richard Sandiford > >> If we go for (

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. For example, on x86_64, the function might >>>

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: > Like I mentioned earlier though, passes that run after > pass_thread_prologue_an

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 set rax to >>> a value the attacker wants a

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>> writes: > On Sep 14, 2020, at 11:33 AM, Richard Sandiford >

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 in DF, inserting the new insns in pro_and_epi). >

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 code after >>> some zeroing can be us

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

Segher and Richard, Now there are two major concerns from the discussion so far: 1. (From Richard): Inserting zero insns should be done after pass_thread_prologue_and_epilogue since later passes (for example, pass_regrename) might introduce new used caller-saved registers. So, we should

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 >> pass_thread_prologue_and_epilogue since later p

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, Now there are two major concerns from the discussion

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 >> zeroing insn for selected registers. Move the gener

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 default definition in the middle end to just use >>

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 an overridden implementation for this target

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 behaviour. >> >> Then, on the target that the defa

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 generate the zeroing insn for selected r

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]

;> >>> 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, Richard Sandiford >>>>&

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 >> > wrote: > 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 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 from i386.md: (I didn’t look at how >> “UNSPEC_volatile” is used in da

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_VOLATILE? >> >> I'm not sure it's written down a

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, 2020, at 1:35 PM, H.J. Lu wrote: > On Tue, Sep 22, 2020 at 11:25 AM Q

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: > On Sep 22, 2020, at 12:06 PM, Richard Sandiford > wrote: The

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 > likely to be useful either. Okay, I will add a

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, 2020, at 6:05 AM, Richard Sandiford > wrote: > > Qing Zhao

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 patch >> >> >> /* The default hook for TARGET_ZERO_

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, As you suggested, I added a default implementation of the tar

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_REG_SET is enough. All the caller needs to know is: which registers >>> were cl

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. */ >> HARD_REG_SET zeroed_hardregs; >>

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 to be committed to upstream. >> Thank

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. >> >> The default implementation now is: >> >> +/* The defau

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 following statement: machine_mode mode = reg_raw_mode[reg

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

Hi, Richard, To answer the question, which registers should be included in “ALL”. I studied X86 hard register set in more details. And also consulted with H.J.Lu, And found: In the current x86 implementation, mask registers, MM0-MM7 registers, and ST0-ST7 registers are not zeroed. The reasons

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 consulted with >> H.J.Lu, And found: >> >> In the curren

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 th

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 *insn = emit_insn (gen_rtx_SET (regno_reg_rtx[regno], zero)); >>> if (!valid_i

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 consulted with >> H.J.Lu, And found: >> >> In the curren

[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, Gcc team, This is the 3rd version of the implementation of patch -fzero-call-used-regs. We will provide a new feature into GCC: Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-arg|used-gpr|all-gpr|used|all] command-line option and zero_call_used_regs("skip|used-gpr-arg|used-arg|a

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

Re: [GCC13][Patch][V4][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_arrays

Hi, Martin, Thanks for the comments. And sorry for my late reply till now (I just came back home from LPC, GNU Cauldron and then a one-week vacation after that…) > On Sep 12, 2022, at 12:42 PM, Martin Sebor wrote: > > On 9/6/22 18:28, Qing Zhao wrote: >> Add the following new option -fstrict-f

Re: [GCC13][Patch][V4][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_arrays

> On Sep 30, 2022, at 1:39 PM, Martin Sebor wrote: > > On 9/28/22 13:17, Qing Zhao wrote: >> Hi, Martin, >> Thanks for the comments. And sorry for my late reply till now (I just came >> back home from LPC, GNU Cauldron and then a one-week vacation after that…) >>> On Sep 12, 2022, at 12:42 PM,

[GCC13][Patch][V5][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array

Add the following new option -fstrict-flex-arrays[=n] and a corresponding attribute strict_flex_array to GCC: '-fstrict-flex-arrays' Control when to treat the trailing array of a structure as a flexible array member for the purpose of accessing the elements of such an array. The pos

[PATCH 0/2] [GCC13][Patch][V5][PATCH 0/2] Add a new option -fstrict-flex-arrays[=n] and attribute strict_flex_array(n) and use it in PR101836

This is the 5th version of the patch set. Compare to the 4th version, the following are the major change:(Address Martin's comments). 1. change the name of the attribute from "strict_flex_arrays" to "strict_flex_array"; 2. update document to update all mentions of flexible array member with

[GCC13][Patch][V5][PATCH 2/2] Use array_at_struct_end_p in __builtin_object_size [PR101836]

Use array_at_struct_end_p to determine whether the trailing array of a structure is flexible array member in __builtin_object_size. gcc/ChangeLog: PR tree-optimization/101836 * tree-object-size.cc (addr_object_size): Use array_at_struct_end_p to determine a flexible array

Re: [GCC13][Patch][V5][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array

> On Oct 4, 2022, at 1:37 PM, Joseph Myers wrote: > > On Tue, 4 Oct 2022, Qing Zhao via Gcc-patches wrote: > >> + { "strict_flex_array", 1, 1, false, false, false, false, >> + handle_strict_flex_array_attribute, NULL },

Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone

Hi, Martin: I have two questions on this: 1. What’s the motivation to enable -flive-patching with -flto? Is there any application that will try -flive-patching with -flto now? 2. Why only enable -flive-patching=inline-clone with -flto? thanks. Qing > On Oct 5, 2022, at 7:41 AM, Martin Lišk

Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone

> On Oct 5, 2022, at 1:36 PM, Martin Liška wrote: > > On 10/5/22 16:50, Qing Zhao wrote: >> I have two questions on this: > > Hello. > >> >> 1. What’s the motivation to enable -flive-patching with -flto? Is there any >> application that will try -flive-patching with -flto now? > > We're p

[GCC13][Patch][V6][PATCH 0/2] Add a new option -fstrict-flex-arrays[=n] and attribute strict_flex_array(n) and use it in PR101836

This is the 6th version of the patch set. Compare to the 5th version, the major change is: (Address Joseph's comment on the attribute): 1. to require the attribute to be applied to a declaration; (c-family/c-attribs.cc) 2. update testing case to include such case; (testsuite/gcc.dg/strict-flex-arr

[GCC13][Patch][V6][PATCH 2/2] Use array_at_struct_end_p in __builtin_object_size [PR101836]

Use array_at_struct_end_p to determine whether the trailing array of a structure is flexible array member in __builtin_object_size. gcc/ChangeLog: PR tree-optimization/101836 * tree-object-size.cc (addr_object_size): Use array_at_struct_end_p to determine a flexible array

[GCC13][Patch][V6][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array

Add the following new option -fstrict-flex-arrays[=n] and a corresponding attribute strict_flex_array to GCC: '-fstrict-flex-arrays' Control when to treat the trailing array of a structure as a flexible array member for the purpose of accessing the elements of such an array. The pos

Re: [GCC13][Patch][V6][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array

> On Oct 5, 2022, at 4:25 PM, Joseph Myers wrote: > > On Wed, 5 Oct 2022, Qing Zhao via Gcc-patches wrote: > >> + /* if not the last field, return false. */ > > Comments should start with an uppercase letter. > >> + /* if not an array field, return fal

Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone

> On Oct 6, 2022, at 4:29 AM, Richard Biener wrote: > > On Wed, Oct 5, 2022 at 8:18 PM Qing Zhao via Gcc-patches > wrote: >> >> >> >>> On Oct 5, 2022, at 1:36 PM, Martin Liška wrote: >>> >>> On 10/5/22 16:50, Qing Zhao

Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone

> On Oct 7, 2022, at 2:34 AM, Richard Biener wrote: > > On Thu, Oct 6, 2022 at 3:18 PM Qing Zhao wrote: >> >> >> >>> On Oct 6, 2022, at 4:29 AM, Richard Biener >>> wrote: >>> >>> On Wed, Oct 5, 2022 at 8:18 PM Qing Zhao via

Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone

> On Oct 7, 2022, at 9:03 AM, Jan Hubicka wrote: > >>> WPA is Whole Program Analysis? >> >> Yes. >> >>> Okay, then It will promote all static function to extern functions. That’s >>> reasonable. >> >> No, all extern functions to static functions. >> >>> Is it hard to preserve the original

Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone

> On Oct 7, 2022, at 10:43 AM, Jan Hubicka wrote: > Probably not hard, and the IPA pass adjusting visbility could as well mark the functions as not to be inlined with -flive-patching=inline-only-static. >> >> OTOH inline-only-static could disable WPA inlining and d

Re: [GCC13][Patch][V6][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array

FYI. I just committed the patches to gcc13: https://gcc.gnu.org/pipermail/gcc-cvs/2022-October/372114.html https://gcc.gnu.org/pipermail/gcc-cvs/2022-October/372115.html thanks. Qing > On Oct 6, 2022, at 8:49 AM, Qing Zhao via Gcc-patches > wrote: > > > >> On Oc

[PATCH][V2][middle-end/102276]Don't emit switch-unreachable warnings for -ftrivial-auto-var-init (PR102276)

Hi, This is the 2nd version of the patch based on the discussion on the initial version. Compared to the previous version, the major changes in this version are: 1. Merged two patches into one; 2. Re-organize the code to emit both Wswitch-unreachable and Wtrivial-auto-var-init Messages

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

> On Mar 9, 2022, at 12:25 PM, Richard Sandiford via Gcc-patches > wrote: > > Xi Ruoyao writes: >> Bootstrapped and regtested on mips64el-linux-gnuabi64. >> >> I'm not sure if it's "correct" to clobber other registers during the >> zeroing of scratch registers. But I can't really come up wi

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

> On Mar 10, 2022, at 8:54 PM, Xi Ruoyao wrote: > > On Thu, 2022-03-10 at 20:31 +, Qing Zhao wrote: > + SET_HARD_REG_BIT (zeroed_hardregs, HI_REGNUM); + if (TEST_HARD_REG_BIT (need_zeroed_hardregs, LO_REGNUM)) + SET_HARD_REG_BIT (zeroed_hardregs, LO_REGNUM);

[PATCH][Middle-end][Backport to GCC11][PR100775]Updating the reg use in exit block for -fzero-call-used-regs

Hi, I plan to backport the patch to fix PR100775: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775 To gcc11 since this is a general bug to -fzero-call-used-regs. And should be fixed in gcc11 as well. I have tested the patch with gcc11 release branch on both x86 and aarch64, no regression

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

Hi, Ruoyao, (I might not be able to reply to this thread till next Wed due to a short vacation). First, some comments on opening bugs against Gcc: I took a look at the bug reports PR104817 and PR104820: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104820 https://gcc.gnu.org/bugzilla/show_bug.cg

Re: [PATCH][Middle-end][Backport to GCC11][PR100775]Updating the reg use in exit block for -fzero-call-used-regs

Thanks. Just committed the patch to gcc11 branch. Qing > On Mar 14, 2022, at 2:46 AM, Richard Biener > wrote: > > On Fri, Mar 11, 2022 at 5:31 PM Qing Zhao via Gcc-patches > wrote: >> >> >> Hi, >> >> I plan to backport the patch to

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

> On Mar 14, 2022, at 11:04 AM, Richard Sandiford > wrote: > > Sorry for the slow response, was out for a few days. > > Xi Ruoyao writes: >> On Sat, 2022-03-12 at 18:48 +0800, Xi Ruoyao via Gcc-patches wrote: >>> On Fri, 2022-03-11 at 21:26 +, Qing Zhao wrote: Hi, Ruoyao,

Re: [PATCH RFC] mips: add TARGET_ZERO_CALL_USED_REGS hook [PR104817, PR104820]

> On Mar 18, 2022, at 11:09 AM, Richard Sandiford > wrote: > > Xi Ruoyao writes: >>> >>> If we have to go this way, I think it’s better to make the change you >>> suggested above, >>> and then also update the documentation, both internal documentation on >>> how to define >>> the hook and

[patch]update the documentation for TARGET_ZERO_CALL_USED_REGS hook and add an assertion

Hi, Per our discussion on: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html I come up with the following patch to: 1. Update the documentation for TARGET_ZERO_CALL_USED_REGS hook; 2. Add an assertion in function.cc to make sure the actually zeroed_regs is a subset of all call

Re: [patch]update the documentation for TARGET_ZERO_CALL_USED_REGS hook and add an assertion

Hi, Richard, Thanks a lot for your reviewing on the non-x86 part. Uros, could you please review the x86 part of the change? thanks. Qing > On Mar 31, 2022, at 8:10 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Hi, >> >> Per our discussion on: >> https://gcc.gnu.org/pipermail/

Re: [patch]update the documentation for TARGET_ZERO_CALL_USED_REGS hook and add an assertion

FYI. I have committed the change to upstream as: 31933f4f788b6cd64cbb7ee42076997f6d0fe212 Qing > On Mar 31, 2022, at 8:10 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Hi, >> >> Per our discussion on: >> https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html >> >> I

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

Hi, Richard, Thanks a lot for taking a look at this issue (and Sorry that I haven’t fixed this one yet, I was distracted by other tasks then just forgot this one….) > On Apr 13, 2022, at 3:41 AM, Richard Biener > wrote: > > On Tue, Feb 15, 2022 at 5:31 PM Qing Zhao via Gcc-patc

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

d by other tasks then just forgot this one….) >> >>> On Apr 13, 2022, at 3:41 AM, Richard Biener >>> wrote: >>> >>> On Tue, Feb 15, 2022 at 5:31 PM Qing Zhao via Gcc-patches >>> wrote: >>>> >>>> >>>> >&

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

g Zhao wrote: >>>> >>>> Hi, Richard, >>>> >>>> Thanks a lot for taking a look at this issue (and Sorry that I haven’t >>>> fixed this one yet, I was distracted by other tasks then just forgot this >>>> one….) >

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

g Zhao wrote: >>>> >>>> Hi, Richard, >>>> >>>> Thanks a lot for taking a look at this issue (and Sorry that I haven’t >>>> fixed this one yet, I was distracted by other tasks then just forgot this >>>> one….) >

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

;>> Hi, Richard, >>>>>> >>>>>> Thanks a lot for taking a look at this issue (and Sorry that I haven’t >>>>>> fixed this one yet, I was distracted by other tasks then just forgot >>>>>> this one….) >>>

[Patch]middle-end: updating the reg use in exit block for -fzero-call-used-regs [PR100775]

Hi, PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775 Although the ICE only happens on arm, but this is a bug in the middle end. So, I think this bug has higher priority, Need to be i

Re: [committed] analyzer: stop -ftrivial-auto-var-init from suppressing uninit warnings [PR104270]

Hi, David, Thank you for fixing this issue! > On Feb 2, 2022, at 9:06 AM, David Malcolm via Gcc-patches > wrote: > > GCC 12 has gained two features for dealing with uninitialized variables: > > (a) a new -Wanalyzer-use-of-uninitialized-value warning within -fanalyzer > for interprocedural pat

Re: [Patch]middle-end: updating the reg use in exit block for -fzero-call-used-regs [PR100775]

Ping. thanks. Qing > On Jan 28, 2022, at 12:03 PM, Qing Zhao via Gcc-patches > wrote: > > Hi, > > PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with > -mthumb -fzero-call-used-regs=used) > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775 &g

[Patch]middle-end: updating the reg use in exit block for -fzero-call-used-regs [PR100775]

Hi, Richard, Could you please review this patch? This is a fix to the previous -fzero-call-used-regs implementation. PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with -mthumb -fzero-call-used-regs=used) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775 Although the ICE

<    1   2   3   4   5   6   7   8   >