Pushed to both gcc11 and gcc12. thanks.
Qing > On May 24, 2022, at 1:19 AM, Richard Biener <rguent...@suse.de> wrote: > > On Mon, 23 May 2022, Qing Zhao wrote: > >> Hi, >> >> I have added the patch to GCC11 and GCC12 in my local area and bootstrapped >> and regress tested on both x86 and aarch64, no any issues. >> >> Can I committed them to both GCC11 and GCC12 branches? > > Yes. > > Thanks, > Richard. > >> Thanks. >> >> >> >> >>> On May 10, 2022, at 8:38 AM, Qing Zhao via Gcc-patches >>> <gcc-patches@gcc.gnu.org> wrote: >>> >>> >>> >>>> On May 10, 2022, at 1:12 AM, Richard Biener <rguent...@suse.de> wrote: >>>> >>>> On Mon, 9 May 2022, Uros Bizjak wrote: >>>> >>>>> On Mon, May 9, 2022 at 5:44 PM Qing Zhao <qing.z...@oracle.com> wrote: >>>>>> >>>>>> Another question: >>>>>> >>>>>> I think that this patch might need to be back ported to Gcc12 and GCC11. >>>>>> >>>>>> What?s your opinion on this? >>>>> >>>>> It is not a regression, so following general rules, the patch should >>>>> not be backported. OTOH, the patch creates functionally equivalent >>>>> code, better in some security aspects. The functionality is also >>>>> hidden behind some non-default flag, so I think if release managers >>>>> (CC'd) are OK with the backport, I'd give it a technical approval. >>>>> >>>>>> If so, when can I backport it? >>>>> >>>>> Let's keep it in the mainline for a week or two, before backporting it >>>>> to non-EoL branches. >>>> >>>> OK from my POV after a week or two on trunk. >>> >>> Sure, I will do the back porting after two weeks. >>> >>> thanks. >>> >>> Qing >>>> >>>> Richard. >>>> >>>>> Uros. >>>>> >>>>>> >>>>>> thanks. >>>>>> >>>>>> Qing >>>>>> >>>>>>> On May 7, 2022, at 4:06 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >>>>>>> >>>>>>> On Fri, May 6, 2022 at 6:42 PM Qing Zhao <qing.z...@oracle.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On May 6, 2022, at 10:58 AM, Uros Bizjak <ubiz...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> On Fri, May 6, 2022 at 4:29 PM Qing Zhao <qing.z...@oracle.com> wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> As Kee?s requested in this PR: >>>>>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 >>>>>>>>>> >>>>>>>>>> ===== >>>>>>>>>> >>>>>>>>>> Currently -fzero-call-used-regs will use a pattern of: >>>>>>>>>> >>>>>>>>>> XOR regA,regA >>>>>>>>>> MOV regA,regB >>>>>>>>>> MOV regA,regC >>>>>>>>>> ... >>>>>>>>>> RET >>>>>>>>>> >>>>>>>>>> However, this introduces both a register ordering dependency (e.g. >>>>>>>>>> the CPU cannot clear regB without clearing regA first), and while >>>>>>>>>> greatly reduces available ROP gadgets, it does technically leave a >>>>>>>>>> set of "MOV" ROP gadgets at the end of functions (e.g. "MOV >>>>>>>>>> regA,regC; RET"). >>>>>>>>>> >>>>>>>>>> Please switch to always using XOR: >>>>>>>>>> >>>>>>>>>> XOR regA,regA >>>>>>>>>> XOR regB,regB >>>>>>>>>> XOR regC,regC >>>>>>>>>> ... >>>>>>>>>> RET >>>>>>>>>> >>>>>>>>>> ======= >>>>>>>>>> >>>>>>>>>> This patch switch all MOV to XOR on i386. >>>>>>>>>> >>>>>>>>>> Bootstrapped and regresstion tested on x86_64-linux-gnu. >>>>>>>>>> >>>>>>>>>> Okay for gcc13? >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Qing >>>>>>>>>> >>>>>>>>>> ========================================== >>>>>>>>> >>>>>>>>>> gcc/ChangeLog: >>>>>>>>>> >>>>>>>>>> * config/i386/i386.cc (zero_all_mm_registers): Use SET to zero >>>>>>>>>> instead >>>>>>>>>> of MOV for zeroing scratch registers. >>>>>>>>>> (ix86_zero_call_used_regs): Likewise. >>>>>>>>>> >>>>>>>>>> gcc/testsuite/ChangeLog: >>>>>>>>>> >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-1.c: Add -fno-stack-protector >>>>>>>>>> -fno-PIC. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-10.c: Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-13.c: Add -msse. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-14.c: Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-15.c: Add -fno-stack-protector >>>>>>>>>> -fno-PIC. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-16.c: Likewise. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-17.c: Likewise. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-18.c: Add -fno-stack-protector >>>>>>>>>> -fno-PIC, adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-19.c: Add -fno-stack-protector >>>>>>>>>> -fno-PIC. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-2.c: Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-20.c: Add -msse. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-21.c: Add -fno-stack-protector >>>>>>>>>> -fno-PIC, Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-22.c: Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-23.c: Likewise. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-26.c: Likewise. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-27.c: Likewise. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-28.c: Likewise. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-3.c: Add -fno-stack-protector. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-31.c: Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-4.c: Add -fno-stack-protector >>>>>>>>>> -fno-PIC. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-5.c: Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-6.c: Add -fno-stack-protector. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-7.c: Likewise. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-8.c: Adjust mov to xor. >>>>>>>>>> * gcc.target/i386/zero-scratch-regs-9.c: Add -fno-stack-protector. >>>>>>>>> >>>>>>>>> Please use something like the attached (functionally equivalent) patch >>>>>>>>> for the last hunk of your patch. >>>>>>>> >>>>>>>> Sure, I will update the code. >>>>>>>>> >>>>>>>>> Also, if possible, please use V2SImode as a generic MMX mode instead >>>>>>>>> of V4HImode. >>>>>>>> What?s the major purpose of this change? >>>>>>> >>>>>>> Although the generated code is the same, V2SI is used as a "generic" >>>>>>> MMX move insn in the same way V2DI is used to describe generic SSE >>>>>>> move instruction. >>>>>>> >>>>>>> Uros. >>>>>> >>>>> >>>> >>>> -- >>>> Richard Biener <rguent...@suse.de> >>>> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, >>>> Germany; GF: Felix Imend >> >> > > -- > Richard Biener <rguent...@suse.de> > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, > Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; > HRB 36809 (AG Nuernberg)
