Ping [PATCH][Middle-end][version 2]2nd patch of PR78809 and PR83026

Hi, I’d like to ping for the following patch: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01454.html thanks a lot. For your reference, the first version of this patch is at: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00962.html

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

; On Fri, 21 Sep 2018, Qing Zhao wrote: >> +2018-09-20 Qing Zhao >> + >> +* cif-code.def (FUNCTION_EXTERN): New CIFCODE. >> +* common.opt (-finline-only-static): New option. >> +* doc/invoke.texi: Document -finline-only-static. >> +* ip

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 8:24 AM, Richard Biener wrote: > > On Wed, 26 Sep 2018, Jason Merrill wrote: > >> On Fri, Sep 21, 2018 at 11:12 AM, Qing Zhao wrote: >>> Hi, this is the 4th version of the patch. >>> >>> mainly address Martin’s comments on

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 9:45 AM, Jeff Law wrote: > > On 9/26/18 7:38 AM, Jason Merrill wrote: >> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener wrote: >>> IIRC he explicitely wanted 'static' not 'hidden' linkage. Not sure >>> what 'internal' would mean in this context. >> >> I mean internal l

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 10:06 AM, Jan Hubicka wrote: > >> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law wrote: >>> On 9/26/18 7:38 AM, Jason Merrill wrote: On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener wrote: > IIRC he explicitely wanted 'static' not 'hidden' linkage. Not sure > wh

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 11:02 AM, Jan Hubicka wrote: > >>> Not sure >>> what 'internal' would mean in this context. >>> >>> But then the implementation looks at callee->externally_visible which >>> matches hidden visibility... externally_visible is probably not >>> the very best thing to look at

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 12:16 PM, Jan Hubicka > wrote: > >>> >>> On Sep 26, 2018, at 10:06 AM, Jan Hubicka >> > wrote: >>> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law >>> > wrote: > On 9/26/18 7:38 AM, Jason Merrill w

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 12:16 PM, Jan Hubicka wrote: > >>> >>> On Sep 26, 2018, at 10:06 AM, Jan Hubicka wrote: >>> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law wrote: > On 9/26/18 7:38 AM, Jason Merrill wrote: >> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener >> wrote:

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 10:16 AM, Alexander Monakov wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: > >> Alexander, >> >> thanks for the questions. >> >> Yes, we had some discussion on the questions you raised during the review of >> the i

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 6:07 PM, Alexander Monakov wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: >> The request is for application developers who want to use gcc's online >> patching feature. >> >> Today, developers can turn off inlining and deliv

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 27, 2018, at 2:45 AM, Richard Biener wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: > >> >>> On Sep 26, 2018, at 6:07 PM, Alexander Monakov wrote: >>> >>> On Wed, 26 Sep 2018, Qing Zhao wrote: >>>> The request i

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 27, 2018, at 3:58 AM, Jan Hubicka wrote: > >> >> Okay, I see. >> >>> >>> If you make this to be INTERPOSABLE (which means it can be replaced by >>> different >>> implementation by linker and that is probably what we want for live >>> patching) >>> then also inliner, ipa-sra and ot

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

Thanks, Martin, for all these interesting information. Looks like that a more general option to help live-patching is needed. I will do a little more study on this direction. Qing > On Sep 27, 2018, at 7:19 AM, Martin Jambor wrote: > > Hi, > > (this message is a part of the thread originatin

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

Hi, Martin, I have studied a little more on https://github.com/marxin/kgraft-analysis-tool/blob/master/README.md in the Section “Usages”, from the example, we can see: the tool will report a list of affected functions for a

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 2, 2018, at 3:33 AM, Martin Jambor wrote: > > Hi, > > my apologies for being terse, I'm in a meeting. > > On Mon, Oct 01 2018, Qing Zhao wrote: >> Hi, Martin, >> >> I have studied a little more on >> >> https://gith

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 2, 2018, at 9:02 AM, Martin Liška wrote: > > On 10/2/18 3:28 PM, Qing Zhao wrote: >> >>> On Oct 2, 2018, at 3:33 AM, Martin Jambor wrote: >>> >>> Hi, >>> >>> my apologies for being terse, I'm in a meetin

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 2, 2018, at 9:55 AM, Martin Liška wrote: Affected functions: 5 __ilog2_u64/132 (include/linux/log2.h:40:5) ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82) ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82) helpe

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 3, 2018, at 4:04 AM, Jan Hubicka wrote: > >> >> That was promised to be done by Honza Hubička. He's very skilled in IPA >> optimizations and he's aware >> of optimizations that cause troubles for live-patching. > > :) I am not sure how skilful I am, but here is what I arrived to. >

Re: [RFC] GCC support for live-patching

Hi, thanks for the comments. > > thanks for the proposal. The others have already expressed some of my > worries and remarks, but I think it would be only right to write them > again. Especially since I am part of the team responsible for > implementation and maintenance of live patches here

Re: [RFC] GCC support for live-patching

> On Oct 23, 2018, at 4:11 AM, Miroslav Benes wrote: >> >> One question here, what’s the major benefit to prepare the patches >> manually? > > I could almost quote what you wrote below. It is a C file, easy to review > and maintain. You have everything "under control". It allows to impleme

[PATCH 1/3][middle-end]PR78809 (Inline strcmp with small constant strings)

aarch64. no regression. Okay for commit? thanks. Qing == gcc/ChangeLog 2017-11-15 Qing Zhao * gimple-fold.c (gimple_fold_builtin_string_compare): Add handling of replacing call to strncmp with corresponding call to strcmp when meeting conditions. gc

Re: [PATCH 1/3][middle-end]PR78809 (Inline strcmp with small constant strings)

> On Nov 16, 2017, at 6:57 PM, Jeff Law wrote: > > On 11/15/2017 08:00 AM, Qing Zhao wrote: >> Hi, >> >> this is the first patch for PR78809 (totally 3 patches) >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 >> inline strcmp with small

Re: [PATCH 1/3][middle-end]PR78809 (Inline strcmp with small constant strings)

thanks Jeff and Paolo. really appreciate for all the help so far. Qing > On Nov 17, 2017, at 3:17 AM, Paolo Carlini wrote: > > Hi, > > On 17/11/2017 06:29, Jeff Law wrote: >> OK. I'll go ahead and commit for you. > Beautiful. Thanks Jeff. >> I think this patch is small enough to not require

Re: [PATCH][Middle-end]patch for fixing PR 86519

Hi, Rainer, thanks a lot to report the issues with mips and sparc platform. Yes, looks like even on the assembly level, the string scanning still not reliable on different platforms. I agree with Jeff’s suggestion to apply different search result for different platforms. I will update the tes

Re: [PATCH][Middle-end]patch for fixing PR 86519

Hi, Paul, I was trying to repeat this issue on a mips machine today, but failed… the only mips machines I can access are those in gcc compile farm, I chose gcc22, but failed to build GCC on this machine. do you know any other machine in gcc compile farm that can repeat this issue? thanks a lot

Re: [PATCH][Middle-end]patch for fixing PR 86519

thanks. now, I can repeat the failure. Qing > On Aug 21, 2018, at 7:25 PM, Paul Hua wrote: > > On Wed, Aug 22, 2018 at 2:15 AM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> >>> On Aug 21, 2018, at 8:07 AM, Paul Hua wrote: >>> >>

Re: [PATCH][Middle-end]patch for fixing PR 86519

Hi, Rainer, >From the comments you put into PR86519, for SPARC, looks like that only 32-bit >sparc has the problem. sparcv9 does NOT have the same issue. I was trying to find the string to represent 32-bit sparc target, but haven’t found it. my guess is: sparc32*-*-*, is this correct? >

Re: [PATCH][Middle-end]patch for fixing PR 86519

> On Aug 22, 2018, at 10:50 AM, Rainer Orth > wrote: > > Hi Qing, > >> From the comments you put into PR86519, for SPARC, looks like that only >> 32-bit sparc has the problem. >> sparcv9 does NOT have the same issue. >> >> I was trying to find the string to represent 32-bit sparc target, but

Re: [PATCH][Middle-end]patch for fixing PR 86519

> On Aug 22, 2018, at 5:01 PM, Jeff Law wrote: > > On 08/22/2018 11:05 AM, Qing Zhao wrote: >> >>> On Aug 22, 2018, at 10:50 AM, Rainer Orth >>> wrote: >>> >>> Hi Qing, >>> >>>> From the comments you put into PR

[PATCH][testcase]patch for fixing PR 86519

) +++ ChangeLog (working copy) @@ -1,3 +1,10 @@ +2018-08-29 Qing Zhao + + PR 86519 + gcc.dg/strcmpopt_6.c: Remove. + gcc.target/aarch64/strcmpopt_6.c: New testcase. + gcc.target/i386/strcmpopt_6.c: Likewise. + 86519_2.patch Description: Binary data

[PATCH][Middle-end]Add a new option to finer control inlining based on function's visibility

nction’s visibility. For example, some online patching users might want to limit the inlining to only static functions to avoid patching the callers of global functions in order to control the memory consumption caused by online patching. let me know any comments and suggestions. thanks. Qing gcc/C

Re: [PATCH][Middle-end]Add a new option to finer control inlining based on function's visibility

Hi, Alexander, thanks for your comments. > On Sep 11, 2018, at 12:48 PM, Alexander Monakov wrote: > > On Tue, 11 Sep 2018, Qing Zhao wrote: >> '-finline-visibility=[all|extern|static]' >> By default, GCC inlines functions without considering their >>

Re: [PATCH][Middle-end]Add a new option to finer control inlining based on function's visibility

> On Sep 12, 2018, at 2:46 AM, Alexander Monakov wrote: > > On Tue, 11 Sep 2018, Qing Zhao wrote: >> no immediate use case for -finline-visibility=extern right now. But I guess >> that GCC developers might use this option to control inlining scope for >> debugging or

Re: [PATCH][Middle-end]Add a new option to finer control inlining based on function's visibility

> On Sep 12, 2018, at 9:33 AM, Richard Biener wrote: > > On Wed, 12 Sep 2018, Qing Zhao wrote: > >> >>> On Sep 12, 2018, at 2:46 AM, Alexander Monakov wrote: >>> >>> On Tue, 11 Sep 2018, Qing Zhao wrote: >>>> no immediate use c

Re: [PATCH][Middle-end]Add a new option to finer control inlining based on function's visibility

> On Sep 12, 2018, at 10:22 AM, Jeff Law wrote: > > On 9/11/18 9:12 AM, Qing Zhao wrote: >> Hi, >> >> This is a simple patch to add a new first-class option >> >> -finline-visibility={all|extern|static} >> >> to finer control inlinin

Re: [PATCH][Middle-end]Add a new option to finer control inlining based on function's visibility

> On Sep 13, 2018, at 2:06 AM, Richard Biener wrote: > > On Wed, 12 Sep 2018, Alexander Monakov wrote: > >> On Wed, 12 Sep 2018, Richard Biener wrote: >>> With LTO "static" is too blurry - would -finline-only-hidden be OK >>> with you? >> >> This doesn't sound right - in non-pic, everything i

[PATCH][Middle-end][Version 2]Add a new option to control inlining only on static functions

suggestions: thanks a lot. Qing gcc/ChangeLog +2018-09-13 Qing Zhao + + * cif-code.def (FUNCTION_EXTERN): New CIFCODE. + * common.opt (-finline-only-static): New option. + * doc/invoke.texi: Document -finline-only-static. + * ipa-inline.c (can_inline_edge_p): Control

Re: [PATCH][Middle-end][Version 2]Add a new option to control inlining only on static functions

> On Sep 14, 2018, at 3:42 PM, Andrew Pinski wrote: > > On Fri, Sep 14, 2018 at 1:34 PM Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> Hi, >> >> this is the 2nd version of the patch to add a new first-class option >> >> -finli

Re: [PATCH][Middle-end][Version 2]Add a new option to control inlining only on static functions

> On Sep 14, 2018, at 3:45 PM, Andrew Pinski wrote: > > On Fri, Sep 14, 2018 at 1:42 PM Andrew Pinski <mailto:pins...@gmail.com>> wrote: >> >> On Fri, Sep 14, 2018 at 1:34 PM Qing Zhao wrote: >>> >>> Hi, >>> >>> th

[PATCH][Middle-end][Version 3]Add a new option to control inlining only on static functions

and let me know any comment and suggestion. thanks. Qing gcc/ChangeLog +2018-09-18 Qing Zhao + + * cif-code.def (FUNCTION_EXTERN): New CIFCODE. + * common.opt (-finline-only-static): New option. + * doc/invoke.texi: Document -finline-only-static. + * ipa-inline.c (can_inl

Re: [PATCH][Middle-end][Version 3]Add a new option to control inlining only on static functions

thanks, Martin. > On Sep 18, 2018, at 5:26 PM, Martin Sebor wrote: >> >> gcc/ChangeLog >> >> +2018-09-18 Qing Zhao mailto:qing.z...@oracle.com>> >> + >> +* cif-code.def (FUNCTION_EXTERN): New CIFCODE. >> +* common.opt (-finline-

[PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

Hi, this is the 4th version of the patch. mainly address Martin’s comments on some spelling issues. I have tested the patch on both x86 and aarch64, no issue. Okay for commit? thanks. Qing. gcc/ChangeLog +2018-09-20 Qing Zhao + + * cif-code.def (FUNCTION_EXTERN): New CIFCODE

PING: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

Hi, I’d like to ping the following patch. https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01238.html Thanks. Qing

Ping: [PATCH][Middle-end][version 3]2nd patch of PR78809 and PR83026

Ping for the following patch sent in 3 months ago in the end of GCC8: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg184075.html I have rebased the patch on the latest GCC9 thunk. bootstraped and tested on both X86 and Aarch64. no regression. the following are more details:

Re: [PATCH][Middle-end][version 3]2nd patch of PR78809 and PR83026

Hi, Jeff, Thanks a lot for your review and comments. I have updated my patch based on your suggestion, and retested this whole patch on both X86 and aarch64. please take a look at the patch again. thanks. Qing > On May 25, 2018, at 3:38 PM, Jeff Law wrote: > So I originally thought you had

committed: [PATCH][Middle-end][version 3]2nd patch of PR78809 and PR83026

Hi, I have committed the patch as revision 261039. thanks. Qing > On May 29, 2018, at 7:08 PM, Qing Zhao wrote: > > Hi, Jeff, > > Thanks a lot for your review and comments. > > I have updated my patch based on your suggestion, and retested this whole > patch

Ping * 4: [PATCH v2] Provide more contexts for -Warray-bounds warning messages

let me know whether it’s okay for committing? It has been waiting for the middle-end review for 2 months already. The implementation is based on what you suggested during the discussion of this problem. Thanks. Qing > On Aug 12, 2024, at 09:50, Qing Zhao wrote: > > Hi, Richard, &

Re: Ping: [PATCH v2] Explicitly document that the "counted_by" attribute is only supported in C.

09:51, Qing Zhao wrote: > > Gentle ping on this simple patch. > > thanks. > > Qing > > > >> On Aug 5, 2024, at 16:17, Qing Zhao wrote: >> >> Compared to the first version, the major changes are: >> >> 1. Changed the error as a warnin

Re: Ping: [PATCH v2] Explicitly document that the "counted_by" attribute is only supported in C.

thanks. Updated per your suggestion and pushed: https://gcc.gnu.org/pipermail/gcc-cvs/2024-September/408749.html Qing > On Sep 3, 2024, at 10:09, Jakub Jelinek wrote: > > On Tue, Sep 03, 2024 at 01:59:45PM +0000, Qing Zhao wrote: >> Hi, Jakub, >> >> I’d like to p

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

ker wrote: >> >> Am Freitag, dem 06.09.2024 um 13:59 + schrieb Qing Zhao: >>> >>>> On Sep 5, 2024, at 18:22, Bill Wendling wrote: >>>> >>>> Hi Qing, >>>> >>>> Sorry for my late reply. >>>>

Re: [PATCH v1] Provide new GCC builtin __builtin_get_counted_by [PR116016]

> On Sep 5, 2024, at 18:22, Bill Wendling wrote: > > Hi Qing, > > Sorry for my late reply. > > On Thu, Aug 29, 2024 at 7:22 AM Qing Zhao wrote: >> >> Hi, >> >> Thanks for the information. >> >> Yes, providing a unary operator

PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is a PING for this patch for gcc11 stage 1. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html <https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html> Please take a look on it. Thanks. Qing > Begin forwarded message: > > From: Qing Zhao

Committed [Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

FYI. > On Apr 23, 2020, at 5:13 PM, David Malcolm wrote: > > May need updating to match the hint message. > > [...] > > This is OK for stage 1 with those nits fixed. I committed the updated patch with all the suggestions today to gcc11 stage1 as: https://gcc.gnu.org/g:530b44094354758d0dea537

Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Kees, > On May 4, 2020, at 1:21 PM, Kees Cook wrote: > > On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote: >> Hi, >> >> This is a PING for this patch for gcc11 stage 1. >> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html

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

know any more comment? thanks. Qing gcc/ChangeLog: 2020-07-13 qing zhao mailto:qing.z...@oracle.com>> 2020-07-13 H.J. Lu mailto:hjl.to...@gmail.com>> * common.opt: Add new option -fzero-call-used-regs. * config/i386/i386.c (i

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

PING^4. Our company is waiting for this patch to be committed to upstream. Thanks a lot. Qing > On Jun 16, 2020, at 7:49 AM, Martin Liška wrote: > > PING^3 > > On 6/2/20 11:16 AM, Martin Liška wrote: >> PING^2 >> On 5/15/20 11:58 AM, Martin Liška wrote: >>> We're in stage1: PING^1 >>> >>>

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

Hi, Thanks a lot for the info. > On Jul 23, 2020, at 5:07 AM, Martin Liška wrote: > > On 7/21/20 6:24 PM, Qing Zhao wrote: >> 4. >> Our company is waiting for this patch to be committed to upstream. > > Hello. > > Please note that patch review can sometimes t

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

On Jul 14, 2020, at 9:45 AM, Qing Zhao via Gcc-patches > wrote: > > Hi, Gcc team, > > This patch is a follow-up on the previous patch and corresponding discussion: > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545101.html > <https://gcc.gnu.org/pipermail/gcc-p

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

jul. 2020 je oseba Qing Zhao <mailto:qing.z...@oracle.com>> napisala: > > > > > > Richard and Uros, > > > > Could you please review the change that H.J and I rewrote based on your > > comments in the previous round of discussion? > > > > This

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

> On Aug 5, 2020, at 9:45 AM, H.J. Lu wrote: > > On Wed, Aug 5, 2020 at 5:34 AM H.J. Lu > wrote: >> >> On Wed, Aug 5, 2020 at 5:31 AM Richard Biener wrote: >>> >>> >>> [PATCH] Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all] >>

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

>> >> From The SECURE project and GCC in GCC Cauldron 2018: >> >> Speaker: Graham Markall >> >> The SECURE project is a 15 month program funded by Innovate UK, to >> take well known security techniques from academia and make them >> generally available in standard compilers, specfically GCC and

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

Hi, Richard, Thanks a lot for your careful review and detailed comments. > On Aug 4, 2020, at 2:35 AM, Richard Biener wrote: > > I have a few comments below - I'm not sure I'm qualified to fully > review the rest though. Could you let me know who will be the more qualified person to fully r

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

> On Aug 6, 2020, at 3:31 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for your careful review and detailed comments. >> >> >>> On Aug 4, 2020, at 2:35 AM, Richard Biener >

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

> On Aug 6, 2020, at 3:37 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > >>>> >>>> From The SECURE project and GCC in GCC Cauldron 2018: >>>> >>>> Speaker: Graham Markall >>>> >>>&g

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

Hi, Richard, > On Aug 5, 2020, at 4:35 PM, Qing Zhao via Gcc-patches > wrote: > > >> >>>>>> + continue; >>>>>> + if (fixed_regs[regno]) >>>>>> + continue; >>>>>> + if (is_live_

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

Hi, Segher, Thanks for your comments. > On Aug 6, 2020, at 6:37 PM, Segher Boessenkool > wrote: > > Hi! > > On Thu, Aug 06, 2020 at 10:31:27AM +0200, Richard Biener wrote: >> Jeff might be, but with the intended purpose (ROP mitigation AFAIU) >> it would be nice for other target maintainers t

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

> On Aug 7, 2020, at 1:21 AM, Richard Biener wrote: > > On Thu, 6 Aug 2020, Kees Cook wrote: > >> On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote: >>> OK, so -fzero-call-used-regs is a ROP mitigation technique. To me >>> it sounded more like a mitigation against information le

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

Hi, Alexandre, Thank you for the comments and suggestions. > On Aug 7, 2020, at 8:20 AM, Alexandre Oliva wrote: > > On Jul 28, 2020, Qing Zhao via Gcc-patches wrote: > >>> 2. The main code generation part is moved from i386 backend to middle-end; >>> 3. Add 4

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

Hi, > On Aug 7, 2020, at 5:59 PM, Segher Boessenkool > wrote: > >> From my understanding (I am not a security expert though), this patch should >> serve two purpose: >> >> 1. Erase the registers upon return to avoid information leak; > > But only some of the registers. All the call-used re

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

>> >>> If so, I am okay with name “call-clobbered” if this name sounds better. >> >> It's more obvious, at least to me. In the current option list of GCC: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options

[PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, David and Jakub, Per the discussion we had for PR94230: provide an option to change the size limitation for -Wmisleading-indent https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 I come up with the following simple patch per David’s sugge

PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Please take a look at the attached patch and let me know your comments. Thanks. Qing gcc/ChangeLog: 2020-04-03 qing zhao * common.opt: Add -flocation-ranges. * doc/invoke.texi: Document it. * toplev.c (process_options): set line_table->default_range_b

Fwd: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Ping. We need this patch for our product building. thanks. Qing > Begin forwarded message: > > From: Qing Zhao via Gcc-patches > Subject: PING [PATCH][gcc][PR94230]provide an option to change the size > limitation for -Wmisleading-indent > Date: April 8, 2020 at 2:39:22

[PATCH][x86][3/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is the 3rd patch of the total 3 patches set for providing the new feature -mzero-caller-saved-regs for linux kernel security improvement. This patch is to Update gcc.target/i386/ret-thunk-2[234].c Qing 0003-Update-gcc.target-i386-ret-thunk-2-234-.c.patch Description: Binary data

[PATCH][x86][2/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is the 2nd patch of the total 3 patches set for providing the new feature -mzero-caller-saved-regs for linux kernel security improvement. This patch is for resolving the new regressions triggered by the first patch. This patch is to Add ix86_any_return_p to check simple_return in a PA

[PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is a PING for an old patch proposed by H. J. Lu on Oct, 2018: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg02079.html This is the first patch of the total 3 patches set, which provides the following new feature: -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all] co

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard And Dave: Thanks a lot for the review and comments. > On Apr 21, 2020, at 1:46 PM, Richard Sandiford > wrote: > > David Malcolm writes: >> On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote >>> >>> Please add: >>> >>> PR c/94230 Will do. >>> * common.opt:

[Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

. Documentation for this new option; 4. Update the testing case location-overflow-test-1.c to include the new hint. Please take a look at this new patch and let me know any new comment. thanks. Qing. gcc/ChangeLog: 2020-04-22 qing zhao PR c/94230 * common.opt: Add -flarge-source-files

Re: [Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard, > On Apr 23, 2020, at 1:27 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> --- >> gcc/c-family/c-indentation.c | 3 +++ >> gcc/common.opt |

[Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard, This is the 3rd version of the patch, updated based on your previous comments. Please take a look at it and let me know whether it’s okay to commit? Thanks a lot for all your help. Qing. gcc/ChangeLog: 2020-04-22 qing zhao PR c/94230 * common.opt: Add -flarge

[Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

. Qing gcc/c-family/ChangeLog: 2020-04-24 qing zhao * c-indentation.c (get_visual_column): Add a hint to use the new -flarge-source-files option. gcc/ChangeLog: 2020-04-24 qing zhao * common.opt: Add -flarge-source-files. * doc/invoke.texi: Document it

Re: [Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, David, > On Apr 24, 2020, at 5:36 PM, David Malcolm wrote: > > On Fri, 2020-04-24 at 17:22 -0500, Qing Zhao wrote: >> Hi, Dave, >> >> Thanks a lot for the review and comments. >> I just updated the patch with all your suggestions, bootstrapped it >>

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 **Compare wi

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 commen

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

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

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

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

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 op

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

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

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

Hi, Alexandre, CC’ing Richard for his comments on this. > On Aug 10, 2020, at 9:39 PM, Alexandre Oliva wrote: >> I think that moving how to zeroing the registers part to each target >> will be a better solution since each target has >> Better idea on how to use the most efficient insns to do th

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

else in this patch sanely. > > > Segher zeroing call-used registers for security purpose 8/19/2020 Qing Zhao = **Motivation: There are two purposes of this patch: 1. ROP mitigation: ROP (Return-oriented programming, https://en.wikipedia.org/wiki/Retu

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

> On Aug 19, 2020, at 5:57 PM, Segher Boessenkool > wrote: > > Hi! > > On Wed, Aug 19, 2020 at 03:05:36PM -0500, Qing Zhao wrote: >> So, cleaning the scratch registers that are used to pass parameters at >> return instructions should >> effectively mi

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

> On Aug 24, 2020, at 5:50 AM, Richard Biener wrote: > > On Tue, 11 Aug 2020, Qing Zhao wrote: > >> Hi, Alexandre, >> >> CC’ing Richard for his comments on this. >> >> >>> On Aug 10, 2020, at 9:39 PM, Alexandre Oliva wrote: >>&g

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

> On Aug 24, 2020, at 12:49 PM, Segher Boessenkool > wrote: > > On Wed, Aug 19, 2020 at 06:27:45PM -0500, Qing Zhao wrote: >>> On Aug 19, 2020, at 5:57 PM, Segher Boessenkool >>> wrote: >>> Numbers on how expensive this is (for what arch, in code s

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

> On Aug 24, 2020, at 12:59 PM, Segher Boessenkool > wrote: > > [ Please quote correctly. I fixed this up a bit. ] > > On Mon, Aug 24, 2020 at 02:47:22PM +, Rodriguez Bahena, Victor wrote: >>> The call-clobbered regs are the only ones you *can* touch. That does >>> not mean you should

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

> On Aug 24, 2020, at 3:20 PM, Segher Boessenkool > wrote: > > Hi! > > On Mon, Aug 24, 2020 at 01:02:03PM -0500, Qing Zhao wrote: >>> On Aug 24, 2020, at 12:49 PM, Segher Boessenkool >>> wrote: >>> On Wed, Aug 19, 2020 at 06:27:45PM -0500, Qi

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

> On Aug 24, 2020, at 3:26 PM, Segher Boessenkool > wrote: > > On Mon, Aug 24, 2020 at 01:48:02PM -0500, Qing Zhao wrote: >> >> >>> On Aug 24, 2020, at 12:59 PM, Segher Boessenkool >>> wrote: >>> >>> [ Please quote correctly.

<    1   2   3   4   5   6   7   8   9   10   >