Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

Hi, David, thanks a lot for your comment. see my reply below > STRICT_ALIGNMENT has a lot of implications. from the definition of STRICT_ALIGNMENT: /* Set this nonzero if move instructions will actually fail to work when given unaligned data. */ #define STRICT_ALIGNMENT 1 for

Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

To be more specified, when reading all the codes corresponding to “STRICT_ALIGNMENT” and “SLOW_UNALIGNMENT_ACCESS” in gcc (NOTE, SLOW_UNALIGNMENT_ACCESS is the same as STRICT_ALIGNMENT when it is NOT defined explicitly, this is the case for SPARC) We can get the following summary: all the

Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

> On Aug 3, 2017, at 11:40 AM, David Miller <da...@davemloft.net> wrote: > > From: Qing Zhao <qing.z...@oracle.com> > Date: Thu, 3 Aug 2017 10:37:15 -0500 > >> all the special handling on STRICT_ALIGNMENT or >> SLOW_UNALIGNMENT_ACCESS in these c

Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

> On Aug 2, 2017, at 6:17 PM, David Miller <da...@davemloft.net> wrote: > > From: Qing Zhao <qing.z...@oracle.com> > Date: Wed, 2 Aug 2017 14:41:51 -0500 > >> so, could you please specify what kind of side effects will have >> when set STRICT_ALIGNMENT to

Re: A potential bug in lra-constraints.c for special_memory_constraint?

thanks for the replying. > On Jul 11, 2017, at 2:44 AM, Eric Botcazou wrote: > >> From the above doc, the major difference between a memory_constraint and a >> special_memory_constraint is: whether "reload can or cannot make them match >> by reloading the address". > >

Re: A potential bug in lra-constraints.c for special_memory_constraint?

> On Jul 11, 2017, at 2:00 PM, Eric Botcazou wrote: > >> the problem I had is: >> >> 1. we added a new special_memory_constraint for misaligned memory access, >> one important requirement for this new special_memory_constraint is, the >> address of the memory access is

Re: A potential bug in lra-constraints.c for special_memory_constraint?

> On Jul 12, 2017, at 10:28 AM, David Miller <da...@davemloft.net> wrote: > > From: Qing Zhao <qing.z...@oracle.com> > Date: Wed, 12 Jul 2017 08:49:52 -0500 > >> and it also clearly mentioned that “specially aligned memory might >> use this cons

A potential bug in lra-constraints.c for special_memory_constraint?

Hi,team: The following doc for memory_constraint and special_memory_constraint seems imply that the handling of the special_memory_constraint in lra-constraints.c is NOT correct: (https://gcc.gnu.org/onlinedocs/gccint/Define-Constraints.html#Define-Constraints) MD Expression:

Re: A potential bug in lra-constraints.c for special_memory_constraint?

> On Jul 11, 2017, at 4:24 PM, Eric Botcazou wrote: > >> we need to generate misaligned load/store insns ONLY for misaligned memory >> access, therefore need a new constraints for misaligned address. > > Why? What happens exactly if the memory access turns out to be

[PATCH] Fix PR81422[aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

Hi, This patch fixes the aarch64 bug 81422 https://gcc.gnu.org/PR81422 Before adding REG_EQUIV notes in the TLS symbol handling code, we should check whether the "dest" is a REG or NOT (sometimes, it's a SUBREG as in this bug). Only when the “dest” is a REG, the note will be added. a new small

[PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

@@ +/* { dg-do compile } */ +/* { dg-options "-mabi=ilp32" } */ + +void f (void *b) +{ + __builtin_update_setjmp_buf (b); +} + -- 1.9.1 > >> On Oct 5, 2017, at 11:50 AM, Richard Earnshaw (lists) >> <richard.earns...@arm.com> wrote: >>

Re: [PATCH][aarch64] Fix pr81356 - copy empty string with wrz, not a ldrb/strb

I think the change is good. But I don’t have the permission for approval… Qing > On Sep 25, 2017, at 12:36 PM, Steve Ellcey wrote: > > Ping. > > Steve Ellcey > sell...@cavium.com > > > On Fri, 2017-09-15 at 11:22 -0700, Steve Ellcey wrote: >> PR 81356 points out that

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

> On Oct 9, 2017, at 11:27 AM, Qing Zhao <qing.z...@oracle.com> wrote: > >> >> On Oct 9, 2017, at 5:33 AM, Richard Earnshaw (lists) >> <richard.earns...@arm.com> wrote: >> >> On 06/10/17 20:56, Qing Zhao wrote: >>> Thanks a lot for Wil

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

> On Oct 9, 2017, at 5:33 AM, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: > > On 06/10/17 20:56, Qing Zhao wrote: >> Thanks a lot for Wilco’s help on this bug. >> >> Yes, Aarch64 does NOT do anything wrong. >> >> T

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

On Oct 9, 2017, at 12:05 PM, Qing Zhao <qing.z...@oracle.com> wrote: > >>>> Thanks a lot for Wilco’s help on this bug. >>>> >>>> Yes, Aarch64 does NOT do anything wrong. >>>> >>>> The implementation of __builtin_update_s

Re: [PATCH] Fix PR81422[aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

HI, Richard, > On Oct 5, 2017, at 9:53 AM, Richard Earnshaw (lists) > wrote: > > Two minor nits to fix: > > - ChangeLog entries should start with a capital letter (s/check/Check/). > - Please use hard tabs rather than 8 consecutive spaces (each of your > new 'if'

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

> On Oct 16, 2017, at 5:52 AM, Wilco Dijkstra <wilco.dijks...@arm.com> wrote: > > Qing Zhao wrote: > >> Is my patch Okay? > > Given it's a mid-end patch this shouldn't be marked as AArch64 specific. > Similarly the PR needs to be updated to say middle-end.

[PATCH][Middle-end]Fix PR80295 [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

during fixing this bug. Okay for trunk? the patch is: gcc/ChangeLog 2017-10-16 Qing Zhao <qing.z...@oracle.com> Wilco Dijkstra <wilco.dijks...@arm.com> * builtins.c (expand_builtin_update_setjmp_buf): Add a converstion to Pmode from the buf_ad

Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

Just a followup on this patch. We did some run-time performance testing internally on this set of change on sparc M8 machine with -mmisalign and -mno-misalign based on the latest upstream gcc for CPU2017 C/C++ SPEED run: ***without -O, -mmisalign slowdown the run-time performance about 4% on

[PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

Hi, This patch fixes the aarch64 bug 80295 https://gcc.gnu.org/PR80295 The aarch64 backend has multiple places that miss the handling of TARGET_ILP32. in the patch, we added correct handling of TARGET_ILP32 into aarch64 backend. a new small testing case is added. bootstrapped and tested on

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

Hi, Andreas, thanks for the comment. > GNU style is line break before the operator, not after. updated per your comment. Qing. --- gcc/config/aarch64/aarch64.c | 12 +--- gcc/config/aarch64/aarch64.h | 2 +- gcc/config/aarch64/aarch64.md |

[PING] [PATCH] Fix PR81422[aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

Ping https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg173877.html > On Sep 19, 2017, at 2:22 PM, Qing Zhao <qing.z...@oracle.com> wrote: > > Hi, > > This patch fixes the aarch64 bug 81422 > https://gcc.gnu.org/PR81422 > > Before adding REG_EQUIV notes i

Re: [PATCH] Fix PR80295[aarch64] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

Richard, thanks for your review and comments. > On Oct 5, 2017, at 11:50 AM, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: > > On 25/09/17 17:35, Qing Zhao wrote: >> >> --- a/gcc/config/aarch64/aarch64.h >> +++ b/gcc/config/aarch64/aarc

Add myself as GCC maintainer

Added myself as GCC maintainer with r255248: https://gcc.gnu.org/ml/gcc-cvs/2017-11/msg00965.html <https://gcc.gnu.org/ml/gcc-cvs/2017-11/msg00965.html> thanks. Qing == ChangeLog +2017-11-29 Qing Zhao <qing.z...@oracle.com> + + * MAINTAINERS (Write Af

Re: [PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

Hi, Martin, thanks for the suggestion, this might be a good enhancement for get_range_strlen for a future work. my understanding is, the current get_range_strlen does not use value range info yet, and also does not handle VLA. we can improve it from both aspects in a later work. Qing >>

Re: [PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

> On Dec 12, 2017, at 10:50 AM, Richard Biener wrote: >>> +return false; + val = fold_build2 (MINUS_EXPR, TREE_TYPE (val), val, + integer_one_node); >>> >>> val = wide_int_to_tree (TREE_TYPE (val),

Re: [PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

> On Dec 14, 2017, at 1:36 PM, Jeff Law <l...@redhat.com> wrote: > > On 12/14/2017 12:22 PM, Qing Zhao wrote: >> >>> On Dec 14, 2017, at 2:05 AM, Richard Biener <rguent...@suse.de >>> <mailto:rguent...@suse.de>> wrote: >>> >>

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

ested on both X86 and Aarch64. no regression. Okay for trunk? thanks. Qing ==== gcc/ChangeLog: 2017-12-11 Qing Zhao <qing.z...@oracle.com <mailto:qing.z...@oracle.com>> PR middle-end/78809 PR middle-end/83026 *

Re: [PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

> On Dec 14, 2017, at 2:05 AM, Richard Biener <rguent...@suse.de> wrote: > > On Wed, 13 Dec 2017, Qing Zhao wrote: > >> Hi, >> >> I updated gimple-fold.c as you suggested, bootstrapped and re-tested on both >> x86 and aarch64. no any issue. >>

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

Hi, Jakub, thanks a lot for your detailed review. > On Dec 14, 2017, at 2:45 PM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Thu, Dec 14, 2017 at 01:45:21PM -0600, Qing Zhao wrote: >> 2017-12-11 Qing Zhao <qing.z...@oracle.com <mailto:qing.z...@oracle.com

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

> On Dec 15, 2017, at 10:42 AM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Fri, Dec 15, 2017 at 10:08:03AM -0600, Qing Zhao wrote: >> a little confused here: >> >> in the current code: >> . the first case is: result = strcmp() != 0 >

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

> On Dec 15, 2017, at 11:47 AM, Jakub Jelinek <ja...@redhat.com> wrote: > > On Fri, Dec 15, 2017 at 11:17:37AM -0600, Qing Zhao wrote: >> HOST_WIDE_INT const_string_leni = -1; >> >> if (idx1) >>{ >> const_string_leni = compute_st

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

Hi, Wilco, thanks a lot for your review and comments. > On Dec 15, 2017, at 6:41 AM, Wilco Dijkstra wrote: > > Hi Qing, > > Just looking at a very high level, I have a few comments: > > 1. Constant folding str(n)cmp - folding is done separately in > fold-const-call.c

Re: [PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

ng: gcc/ChangeLog 2017-12-13 Qing Zhao <qing.z...@oracle.com > PR middle_end/79538 * gimple-fold.c (get_range_strlen): Add the handling of non-member array. gcc/fortran/ChangeLog 2017-12-13 Qing Zhao <qing.z...@oracle.com > PR middle_end/79538 * class.c (gf

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

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

> On Nov 16, 2017, at 6:57 PM, Jeff Law <l...@redhat.com> 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

[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 <qing.z...@oracle.com> * gimple-fold.c (gimple_fold_builtin_string_compare): Add handling of replacing call to strncmp with corresponding call to strcmp

Patch to fix an undefined behavior in fortran/decl.c

runk? thanks. Qing gcc/fortran/ChangeLog 2017-11-30 Qing Zhao <qing.z...@oracle.com <mailto:qing.z...@oracle.com>> * fortran/decl.c (gfc_get_pdt_instance): Adjust the call to sprintf to avoid t

[PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

= gcc/ChangeLog 2017-11-30 Qing Zhao <qing.z...@oracle.com <mailto:qing.z...@oracle.com>> PR middle_end/79538 * gimple-fold.c (get_range_strlen): Add the handling of non-member array. gcc/fortran/ChangeLog 2017-11-30 Qing Zhao <q

Re: [PATCH][Middle-end]79538 missing -Wformat-overflow with %s and non-member array arguments

Hi, Richard, thanks a lot for your review. > >>{ >> /* __copy is always the same for characters. >> Check to see if copy function already exists. */ >> - sprintf (name, "__copy_character_%d", ts->kind); >> +

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:

[PATCH][Middle-end]3rd patch of PR78809

he threshold is 3. this value of the threshold can be adjusted by the new option: --param builtin-string-cmp-inline-length= The following is the patch. thanks. Qing gcc/ChangeLog: +2018-06-18 Qing Zhao + + PR middle-end/78809 + * builtins.c (expand_builtin_memcmp): Inlin

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

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

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

> On Jun 22, 2018, at 11:49 PM, Jeff Law wrote: > > On 05/29/2018 06: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 >> patc

Re: [PATCH][Middle-end]3rd patch of PR78809

patch for issuing warning for strcmp/strncmp when -Wstringop-overflow is specified. The new patch is as following, please take a look at it. thanks. Qing gcc/ChangeLog +2018-07-02 Qing Zhao + + PR middle-end/78809 + * builtins.c (expand_builtin_memcmp): Inline the calls first

[version 2] Re: [PATCH][Middle-end]3rd patch of PR78809

work on this separate patch for issuing warning for strcmp/strncmp when -Wstringop-overflow is specified. The new patch is as following, please take a look at it. thanks. Qing gcc/ChangeLog +2018-07-02 Qing Zhao + + PR middle-end/78809 + * builtins.c (expand_builtin_memcmp): Inline the calls

Test (please ignore)

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

Hi, I’d like to ping the following patch the 2nd time: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01454.html I already addressed all the issues raised for the first version of the patch, and retested on both X86 and Aarch64, without any issue. I’d really like to make it into GCC 8.

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

Hi, Jeff, Really sorry for my delay. Your email on 1/12/2018 and Richard’s email on 1/15/2018, were completely lost in my mailboxes until yesterday my colleague, Paolo Carlini, forwarded it to me. I really apologize for the late reply. Please see my reply below: > On Jan 12, 2018, at

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

> > We're now in stage4 so please queue this patch and ping it during > next stage1. > I will update my patch based on Jeff and your comments, and send it during next stage 1. thanks. Qing

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

Hi, this is the 3rd version for this patch. the main change compared with 2nd version are: 1. do not use “compute_objsize” to get the minimum object size per Jeff and Richard’s comment. Instead, add a new function “determine_min_objsize” for this purpose. This new function calls

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

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

/ChangeLog: +2017-12-21 Qing Zhao <qing.z...@oracle.com> + + PR middle-end/78809 + PR middle-end/83026 + * builtins.c (expand_builtin): Add the handling of BUILT_IN_STRCMP_EQ + and BUILT_IN_STRNCMP_EQ. + * builtins.def: Add new builtins BUILT_IN_STR

Re: [PATCH][Middle-end] disable strcmp/strncmp inlining with O2 below and Os

> On Jul 26, 2018, at 3:26 AM, Richard Biener wrote: > > On Wed, 25 Jul 2018, Qing Zhao wrote: > >> Hi, >> >> As Wilco suggested, the new added strcmp/strncmp inlining should be only >> enabled with O2 and above. >> >> this is the simple

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

> On Aug 14, 2018, at 11:25 PM, Jeff Law wrote: > > On 08/14/2018 08:57 AM, Qing Zhao wrote: >> Hi, >> >> PR 86519:New test case gcc.dg/strcmpopt_6.c fails with its introduction in >> r262636. >> >> gcc/ChangeLog: >> >> +2

Re: [PATCH][Middle-end] disable strcmp/strncmp inlining with O2 below and Os

Hi, Christophe, I have attached a patch in PR86519, could you please download it and test it, and let me know the result. thanks. Qing > On Jul 30, 2018, at 8:45 AM, Christophe Lyon > wrote: > > On Wed, 25 Jul 2018 at 19:08, Qing Zhao <mailto:qing.z...@oracle.com>

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

g the .expand file to match the string “__builtin_memcmp”, scanning the final assembly file to match the string “memcmp”. please review the attached simple patch. thanks. Qing gcc/ChangeLog: +2018-08-14 Qing Zhao + + PR testsuite/86519 + * builtins.c (expand_builtin_memcmp): Do not expand the

Re: [PATCH][Middle-end] disable strcmp/strncmp inlining with O2 below and Os

thanks for reporting this issue. I will take a look. Qing > On Jul 30, 2018, at 8:45 AM, Christophe Lyon > wrote: > > On Wed, 25 Jul 2018 at 19:08, Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> >> Hi, >> >> As Wilco suggested, the new

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

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

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

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,

Re: [PATCH][Middle-end][version 2]change char type to unsigned char type when expanding strcmp/strncmp

> On Jul 20, 2018, at 9:59 AM, Jakub Jelinek wrote: > > On Fri, Jul 20, 2018 at 09:53:24AM -0500, Qing Zhao wrote: >> +2018-07-20 Qing Zhao >> + >> + * builtins.c (expand_builtin_memcmp): Delete the last parameter for >> + call to

[PATCH][Middle-end][version 2]change char type to unsigned char type when expanding strcmp/strncmp

. and 3. also updated comments of routine inline_string_cmp to reflect the conversions in the expanded code. have tested on X86 and aarch64. No regressions. Okay for thunk? Qing gcc/ChangeLog: +2018-07-20 Qing Zhao + + * builtins.c (expand_builtin_memcmp): Delete the last parameter

Re: [PATCH][Middle-end][version 2]change char type to unsigned char type when expanding strcmp/strncmp

the patch was committed as: https://gcc.gnu.org/viewcvs/gcc?view=revision=262907 <https://gcc.gnu.org/viewcvs/gcc?view=revision=262907> thanks. Qing > On Jul 20, 2018, at 9:59 AM, Jakub Jelinek wrote: > > On Fri, Jul 20, 2018 at 09:53:24AM -0500, Qing Zhao wrote: >> +

[PATCH][Middle-end]change char type to unsigned char type when expanding strcmp/strncmp

should use unsigned char for all strcmp/strncmp/memcmp. the change is quite simple, and I have tested it on X86, aarch64 and powerPC, no regressions. Okay for trunk? Qing gcc/ChangeLog: +2018-07-19 Qing Zhao + + * builtins.c (expand_builtin_memcmp): Delete the last parameter for +

Re: [PATCH][Middle-end]change char type to unsigned char type when expanding strcmp/strncmp

Jakub, thanks a lot for you review and comments. > On Jul 19, 2018, at 12:31 PM, Jakub Jelinek wrote: > > On Thu, Jul 19, 2018 at 11:49:16AM -0500, Qing Zhao wrote: >> As Wilco mentioned in PR78809 after I checked in the last part of >> implementation of inline str

Re: [PATCH][Middle-end]change char type to unsigned char type when expanding strcmp/strncmp

> On Jul 19, 2018, at 2:24 PM, Jakub Jelinek wrote: > > On Thu, Jul 19, 2018 at 02:06:16PM -0500, Qing Zhao wrote: >>> If you expand it as (int) ((unsigned char *)p)[n] - (int) ((unsigned char >>> *)q)[n] >>> then aren't you relying on int type to have wid

[PATCH][Middle-end] disable strcmp/strncmp inlining with O2 below and Os

Hi, As Wilco suggested, the new added strcmp/strncmp inlining should be only enabled with O2 and above. this is the simple patch for this change. tested on both X86 and aarch64. Okay for thunk? Qing gcc/ChangeLog: +2018-07-25 Qing Zhao + + * builtins.c

[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

Re: [PATCH][Middle-end]3rd patch of PR78809

patch is needed. if this is needed, let me know, I can work on this separate patch for issuing warning for strcmp/strncmp when -Wstringop-overflow is specified. The new patch is as following, please take a look at it. thanks. Qing gcc/ChangeLog +2018-07-02 Qing Zhao + + PR middle-end

Re: [PATCH][Middle-end]3rd patch of PR78809

Hi, Martin, thanks a lot for your comments. > On Jul 5, 2018, at 11:30 AM, Martin Sebor wrote: > > One of the basic design principles that I myself have > accidentally violated in the past is that warning options > should not impact the emitted object code. I don't think > your patch

Re: [PATCH][Middle-end]3rd patch of PR78809

> On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote: > > check_access() calls warning_at() to issue warnings, and that > function only issues warnings if they are enabled, so the guard > isn't necessary to make it work this way. Okay I see. then, in the current code: (for routine

Re: [PATCH][Middle-end]3rd patch of PR78809

Richard and Martin, thanks for the info. > On Jul 10, 2018, at 11:29 AM, Richard Biener wrote: >> Is the above condition on variable warn_stringop_overflow unnecessary? >> all the warnings inside check_access are controlled by >> OPT_Wstringop_overflow_. > > Well, the condition certainly saves

Re: [PATCH][Middle-end][version 3]3rd patch of PR78809

thank you. the patch was just committed into trunk as: https://gcc.gnu.org/viewcvs/gcc?view=revision=262636 <https://gcc.gnu.org/viewcvs/gcc?view=revision=262636> Qing > On Jul 12, 2018, at 12:03 PM, Jeff Law wrote: > >> >> gcc/ChangeLog: >> >> +201

[PATCH][Middle-end][version 3]3rd patch of PR78809

e testsuite, change the new testcase strcmpopt_6.c to inhibit inlining when check_access detects error (Not depend on whether the warning option is ON or not). the following is the new patch, tested on both X86 and aarch64, no regression. Okay for thunk? thanks. Qing gcc/ChangeLog: +2018-07-11

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

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/ChangeLog: +2018-09-11 Qing Zhao + + * cif-code.def

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

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

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

>>> - ipa-pta (disabled by default, -fno-ipa-pta) - ipa-reference (list of accessed/modified global vars), disable by -fno-ipa-refernece - stack alignment requirements (no flag to disable) >>> >>> Would it be possible to add flag for it? Can you please point to a location

Re: [PATCH][RFC] Come up with -flive-patching master option.

Hi, > On Nov 10, 2018, at 2:51 AM, Martin Liška wrote: > > On 11/9/18 6:43 PM, Qing Zhao wrote: >> Hi, Martin, >> >> thanks a lot for the previous two new options for live-patching. >> >> >> I have two more questions below: > > Hello. &

Re: [PATCH][RFC] Come up with -flive-patching master option.

Hi, Martin, thanks a lot for the previous two new options for live-patching. I have two more questions below: 1. do we still need new options to disable the following: A. unreachable code/variable removal? B. Visibility changes with -flto and/or -fwhole-program? 2. for this new patch,

Re: [PATCH][RFC] Come up with -flive-patching master option.

> On Nov 12, 2018, at 2:53 AM, Martin Liška wrote: > >> >> Okay, I see. >> >> I am also working on a similar option as yours, but make the -flive-patching >> as two level control: >> >> +flive-patching >> +Common RejectNegative Alias(flive-patching=,inline-clone) >> + >> +flive-patching=

Re: [PATCH][RFC] Come up with -flive-patching master option.

Hi, > On Nov 13, 2018, at 1:18 PM, Miroslav Benes wrote: > >> Attached is the patch for new -flive-patching=[inline-only-static | >> inline-clone] master option. >> >> '-flive-patching=LEVEL' >> Control GCC's optimizations to provide a safe compilation for >> live-patching. Provides

[PATCH][RFC] Come up with -flive-patching master option.

g flive-patching.patch Description: Binary data > On Nov 12, 2018, at 4:29 PM, Qing Zhao wrote: > > >> On Nov 12, 2018, at 2:53 AM, Martin Liška wrote: >> >>> >>> Okay, I see. >>> >>> I am also working on a similar opti

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

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://github.co

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 meeting. &g

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

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

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

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. >> +*

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 >

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

  1   2   3   4   5   6   7   8   9   10   >