[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 --- Comment #8 from Qing Zhao --- > On Feb 16, 2023, at 2:35 AM, rguenther at suse dot de > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 > > --- Comment #7 from rguenther at suse dot de --- > On Wed, 15 Feb 2023, qinzhao

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952 --- Comment #15 from Qing Zhao --- > On Jan 25, 2023, at 11:12 AM, siddhesh at gcc dot gnu.org > wrote: >> >>> The first is handled by the function just fine, >> >> No, even the first case is not recognized by the current >>

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952 --- Comment #13 from Qing Zhao --- > On Jan 25, 2023, at 2:32 AM, rguenther at suse dot de > wrote: >> >> A little confused here: >>when the structure with a trailing flexible-array member is a middle >> field of >>an

[Bug tree-optimization/107952] tree-object-size: inconsistent size for flexible arrays nested in structs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952 --- Comment #10 from Qing Zhao --- > --- Comment #9 from Richard Biener --- > > GCC handles for example > > struct A { char data[1]; }; > struct B { int n; struct A a; }; > > as if the a.data[] array is a flex-array. Okay. Then the maximum

[Bug rtl-optimization/108132] Wrong instruction scheduling around function call with longjmp on aarch64 at O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132 --- Comment #7 from Qing Zhao --- > On Dec 15, 2022, at 2:33 PM, pinskia at gcc dot gnu.org > wrote: > > > There is a patch in PR 57067 even which you could try to port to a newer > compiler version and fix up. Okay, will check that patch.

[Bug target/106270] [Aarch64] -mlong-calls should be provided on aarch64 for users with large applications

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270 --- Comment #4 from Qing Zhao --- > On Jul 12, 2022, at 1:02 PM, wilco at gcc dot gnu.org > wrote: > > Note that GCC could split huge .text sections automatically to allow insertion > of linker veneers every 128MB. Does GCC do this by

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #27 from Qing Zhao --- > On Jun 14, 2022, at 11:39 AM, siddhesh at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 > > --- Comment #26 from Siddhesh Poyarekar --- > (In reply to qinzhao from

[Bug target/101891] Adjust -fzero-call-used-regs to always use XOR

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 --- Comment #8 from Qing Zhao --- > On May 24, 2022, at 11:42 AM, arjan at linux dot intel.com > wrote: > > --- Comment #7 from Arjan van de Ven --- > from a performance angle, the xor-only sequence is not so great at all; modern > CPUs are

[Bug middle-end/105539] -ftrivial-auto-var-init=zero happening too late?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539 --- Comment #9 from Qing Zhao --- > It's a conditional uninit use which we do not warn on early by design > (for the fear of too many false positives, that is). Okay. > >> 2. the ccp optimization deletes the if (z) statement completely: >>

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #20 from Qing Zhao --- > On Feb 21, 2022, at 1:56 AM, rguenth at gcc dot gnu.org > wrote: >> >> my question is, is the "info" in __builtin_clear_padding() a REAL use >> of "info"? is it correct to report the uninitialized use

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #14 from Qing Zhao --- > On Feb 17, 2022, at 1:54 AM, rguenther at suse dot de > wrote: >> >> If padding clearing is exposed too late till RTL expansion, some tree >> optimization will not be able to be applied on the expanded

[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #5 from Qing Zhao --- > On Feb 15, 2022, at 3:38 PM, pinskia at gcc dot gnu.org > wrote: > Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct > vx_audio_level *)]" as not needing a warning. > This sound like

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 --- Comment #27 from Qing Zhao --- > On Feb 11, 2022, at 11:47 AM, jakub at gcc dot gnu.org > wrote: > But if I do: > struct C { char a; int b; char c; long d; C () : a (42), b (42), c (42), d > (42) > {} }; > void bar (C *); > void > foo ()

[Bug tree-optimization/102586] [12 Regression] ICE in clear_padding_type, at gimple-fold.c:4798 since r12-3433-ga25e0b5e6ac8a77a

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586 --- Comment #23 from Qing Zhao --- > On Feb 11, 2022, at 9:29 AM, jason at gcc dot gnu.org > wrote: > > I wonder why -fauto-var-init uses builtin_clear_padding instead of just > zero-initializing the whole object before normal

[Bug target/103271] ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271 --- Comment #4 from Qing Zhao --- > > You should be able to simply do > > ../configure --target=riscv64-linux > make all-gcc > > and use the built gcc/cc1 to debug such ICEs. > Thanks. Yes, I can repeat the ICE with this gcc even though

[Bug middle-end/103127] ICE in fold_convert_loc with __vector_quad and -ftrivial-auto-var-init=pattern on powerpc64*

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127 --- Comment #9 from Qing Zhao --- > On Nov 8, 2021, at 1:56 PM, bergner at gcc dot gnu.org > wrote: > > > So this then? This is better, I think. You can send a patch review request to gcc-patch alias for more comments or approval.

[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 --- Comment #10 from Qing Zhao --- > On Oct 11, 2021, at 3:29 PM, jakub at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 > > --- Comment #8 from Jakub Jelinek --- > (In reply to qinzhao from comment #7)

[Bug target/102683] [12 Regression] ICE in set_min_and_max_values_for_integral_type, at stor-layout.c:2851

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102683 --- Comment #5 from Qing Zhao --- > --- Comment #4 from Richard Biener --- > But we should avoid > the .DEFERRED_INIT here. The GENERIC is > >struct C y; > < (void) (y = n == 1 ? TARGET_EXPR : TARGET_EXPR {.c=__complex__ (3.0e+0,

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #16 from Qing Zhao --- > On Oct 1, 2021, at 1:51 AM, rguenth at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 > > --- Comment #13 from Richard Biener --- > Because the variable doesn't need to

[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #5 from Qing Zhao --- > On Sep 13, 2021, at 4:45 PM, pinskia at gcc dot gnu.org > wrote: > >> is it possible to make -fsanitize=signed-integer-overflow work with -fwrapv? > > Why would it? they conflict. This is a feature that

[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes many crashes in the testsuite

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #4 from Qing Zhao --- > On Sep 10, 2021, at 5:34 PM, pinskia at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 > > --- Comment #3 from Andrew Pinski --- > I wonder if most of these were fixed

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 --- Comment #9 from Qing Zhao --- > On Jul 23, 2021, at 10:34 AM, jakub at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 > > --- Comment #8 from Jakub Jelinek --- > (In reply to Qing Zhao from comment #7)

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 --- Comment #7 from Qing Zhao --- > On Jul 23, 2021, at 10:10 AM, jakub at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586 > > --- Comment #6 from Jakub Jelinek --- > It is related to the weird FIELD_DECLs

[Bug rtl-optimization/99421] ICE:in code_motion_process_successors, at sel-sched.c:6389 on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421 --- Comment #8 from Qing Zhao --- > On Mar 8, 2021, at 11:58 AM, marxin at gcc dot gnu.org > wrote: > > Sure. I used C-Vise: > https://github.com/marxin/cvise >From my understanding, cvise is similar as creduce, but faster. So, I am still

[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #10 from Qing Zhao --- > but it will still fail on all targets but x86_64 (and now powerpc). Qinzhao, > what's the list of targets this is supported? I believe that the targets that currently support this feature are: x86-64

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #21 from Qing Zhao --- > --- Comment #19 from Jakub Jelinek --- > And, actually the function.c change is probably unnecessary, because the > if (!crtl->abi->clobbers_full_reg_p (regno)) >continue; > if

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #20 from Qing Zhao --- > On Nov 4, 2020, at 11:48 AM, jakub at gcc dot gnu.org > wrote: > > --- Comment #18 from Jakub Jelinek --- > --- gcc/function.c.jj 2020-10-31 17:41:19.756740009 +0100 > +++ gcc/function.c 2020-11-04

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #17 from Qing Zhao --- > On Nov 4, 2020, at 10:08 AM, ubizjak at gmail dot com > wrote: >> >> I used the following in middle end to exclude fixed registers from being >> zeroed: >> if (fixed_regs[regno]) >>continue;

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #13 from Qing Zhao --- > On Nov 4, 2020, at 10:04 AM, jakub at gcc dot gnu.org > wrote: > --- Comment #11 from Jakub Jelinek --- > I think you should do: > --- gcc/function.c 2020-10-31 17:41:19.756740009 +0100 > +++

[Bug target/97715] [11 Regression] ICE in insn_default_length, at config/i386/i386.md:15325 since r11-4578-gd10f3e900b0377b4

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715 --- Comment #10 from Qing Zhao --- > On Nov 4, 2020, at 9:45 AM, ubizjak at gmail dot com > wrote: >> fixed registers should already be excluded from zeroing. >> are ST registers considered FIXED registers when -mno-80387 is specified? > >

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #34 from Qing Zhao --- > >> Though still bigger than what ICC generated. > > Yep, but we should be only 2x bigger right now? Yes, around 2-3 times bigger, much better now. > > Can you please test the parallel merging script? I can

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #32 from Qing Zhao --- > I would be more interested in overall statistics for your training scenario. > How much can you get from ~1TB of data? The profile directory generated by the new executable compiled with this patch was 112G

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #31 from Qing Zhao --- > The explanation is not sufficient. You mean the following explanation: (in comment 18) we tried the scheme that all the processes generate profiling feedback data to the single directory, but looks like a

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #29 from Qing Zhao --- > > And you still haven't replied to my essential question: Why can't you merge > profiles into one directory during run? Or at least merge to a reasonable > number of folders that you'll merge later? Comment

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #26 from Qing Zhao --- > --- Comment #25 from Martin Liška --- >> I will try to get more data on our real application. >> >> one question: why not just delete the entire records whose counter is zero >> and delete the entire file

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #19 from Qing Zhao --- Hi, Martin, I attached 3 profiling data files with this email (among over 5000 files under one typical directory), Hope this is helpful. Thanks. Qing

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #20 from Qing Zhao --- Created attachment 48653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48653=edit A.data --- Comment #21 from Qing Zhao --- Created attachment 48654 -->

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #14 from Qing Zhao --- > > -fprofile-dir=gcc_prof_dir/%p" > > So my recommendation would be not to use it and let GCOV run-time library > merge > the profiles. Of course, I'll be interested in `perf report` of such a >

[Bug gcov-profile/95348] GCC records zero functions and modules in the profiling data file, ICC does NOT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348 --- Comment #13 from Qing Zhao --- > The only exception is a cross-profiling: > https://gcc.gnu.org/onlinedocs/gcc/Cross-profiling.html > > where one can use GCOV_PREFIX environment variable to save .gcda files to a > separate location. > > Do

[Bug gcov-profile/47618] Collecting multiple profiles and using all for PGO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618 --- Comment #27 from Qing Zhao --- > --- Comment #26 from Martin Liška --- > >> 2. Intel compiler (icc)'s profmerge is able to merge all the .dyn files >> under one directory, does gcc have such functionality currently? > > We have

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #13 from Qing Zhao --- > --- Comment #12 from seurer at gcc dot gnu.org --- > gcc.dg/strcmpopt_6.c was recently updated in r263028 but it still fails albeit > differently: this is expected, I will provide a separate fix for this one.

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #44 from Qing Zhao --- > (In reply to wilco from comment #43) will provide a simple patch for this issue.

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #11 from Qing Zhao --- > to reply: Comment #10 from Martin Sebor — thanks for the details. However, I do not feel comfortable for the compiler to change an undefined buggy code. I think that it’s better to let the user to correct

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #9 from Qing Zhao --- > --- Comment #8 from Martin Sebor --- > FWIW, it would be safer and more deterministic to fold these invalid calls to > some non-zero value that it is to emit the invalid library call. could you please provide

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #5 from Qing Zhao --- > --- Comment #4 from seurer at gcc dot gnu.org --- > I also just tried it on gcc110 and indeed it does not fail there. However, it > does fail on gcc112. thanks a lot. will try on gcc112.

[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #3 from Qing Zhao --- > --- Comment #2 from seurer at gcc dot gnu.org --- > What system are you testing on? I've seen the same failure on power 8 and > power 9 LE systems and power 7 and power 8 BE systems. I am using the GCC farm

[Bug tree-optimization/86526] [9 Regression] ICE in builtin_memcpy_read_str, at builtins.c:3017

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86526 --- Comment #4 from Qing Zhao --- > On Jul 16, 2018, at 5:01 AM, jakub at gcc dot gnu.org > wrote: > --- Comment #3 from Jakub Jelinek --- > As the patch contains a lot of formatting fixes (Qing, please watch out > formatting of your patches

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #41 from Qing Zhao --- > --- Comment #40 from Wilco --- > See eg. http://www.iso-9899.info/n1570.html section 7.24.4: > > "The sign of a nonzero value returned by the comparison functions memcmp, > strcmp, and strncmp is determined

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #39 from Qing Zhao --- > --- Comment #38 from Wilco --- > This uses signed char while the C standard says the comparison is done on > unsigned chars. > during my implementation, I did some research on whether I should use

[Bug middle-end/86467] inlining strcmp with small known length array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86467 --- Comment #2 from Qing Zhao --- > --- Comment #1 from Richard Biener --- > I think there's a duplicate report. you mean another similar PR existing?

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #33 from Qing Zhao --- with SPEC2017 on X86, I didn't see any run-time performance change as expected. due to the date I collected for code size change, looks like that n=3 or n=4 might be a reasonable default. n=3 might be safer.

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #32 from Qing Zhao --- Created attachment 43298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43298=edit code size impact from inlining str(n)cmp with different n on X86

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #30 from Qing Zhao --- (in reply to Wilco from comment #29) > > The new test is better, however it uses i % 15 which means an expensive > division by constant every loop iteration. It's best to change to i & 15. Also > using an

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #28 from Qing Zhao --- > > I don't think this is a good test. Repeatedly calling strcmp with the same > inputs is not something real code does, especially when the string matches > exactly. Why would it do that? The consequence

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 Qing Zhao changed: What|Removed |Added Attachment #42449|0 |1 is obsolete|

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #24 from Qing Zhao --- From the above, we can see: even with n is as big as 20, inlined version is much faster than the non-inlined version, both on aarch64 (no hardware string compare insn provided) and X86 (hardware string

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #23 from Qing Zhao --- I have an implementation for the part C of this task in my private space: part C: for strcmp (s1, s2), strncmp (s1, s2, n): if the result is NOT used to do simple equality test against zero, one of

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #22 from Qing Zhao --- https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00962.html 2nd patch

[Bug middle-end/79538] missing -Wformat-overflow with %s and non-member array arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79538 Qing Zhao changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug middle-end/79538] missing -Wformat-overflow with %s and non-member array arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79538 --- Comment #4 from Qing Zhao --- fixed in https://gcc.gnu.org/viewcvs/gcc?view=revision=255654

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 --- Comment #4 from Qing Zhao --- Note, this optimization is only valid when the result of the strcmp is used to compare with zero.

[Bug middle-end/79538] missing -Wformat-overflow with %s and non-member array arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79538 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #2

[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #2

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #20 from Qing Zhao --- design doc is at: https://www.mail-archive.com/gcc@gcc.gnu.org/msg83822.html

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #17 from Qing Zhao --- (In reply to Wilco from comment #16) >> const char s[8] = “abcd\0abc”; // null byte in the middle of the string >> int f2(void) { return __builtin_strcmp(s, "abc") != 0; } >> int f3(void) { return

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #15 from Qing Zhao --- (In reply to Wilco from comment 14) > The only reason we have to do a character by character comparison is because > we > cannot read beyond the end of a string. However when we know the size or > alignment we

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #13 from Qing Zhao --- (In reply to Richard Earnshaw from comment 12) > That's not entirely correct. Notionally memcmp needs to return a value > representing the relative difference of the first different byte in the > compared

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #11 from Qing Zhao --- (In reply to Wilco from comment #9) > str(n)cmp with a constant string can be changed into memcmp if the string has > a > known alignment or is an array of known size. We should check the common cases > are

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #10 from Qing Zhao --- >> From the data, we can see the inlined version of strcmp (by glibc) is much >> slower than the direct call to strcmp. (this is for size 2) >> I am using GCC farm machine gcc116: > > This result doesn't make

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #7 from Qing Zhao --- I have studied the inlining of memcmp and str(n)cmp in GCC, the following are a summary of my study so far: 1. memcmp is different from str(n)cmp as the following: • strcmp compares

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #6 from Qing Zhao --- (A correction to comment 4: when adding #include , the call to strcmp(s, "a") was inlined by glibc in the header with the latest upstream GCC ) with attached testing case, on GCC farm machine gcc116, I got

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #5 from Qing Zhao --- Created attachment 42449 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42449=edit Run time performance testing case on aarch64 this is for testing the run-time performance of inlined version of strcmp

[Bug middle-end/78809] Inline strcmp with small constant strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #3

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #10 from Qing Zhao --- Comment on attachment 42319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42319 proposed patch The implementation of __builtin_update_setjmp_buf is incorrect. It takes a pointer as an operand and treats

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #9 from Qing Zhao --- Created attachment 42319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42319=edit proposed patch

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #7 from Qing Zhao --- thank you, Wilco. > Wilco changed: > > What|Removed |Added > > CC|

[Bug rtl-optimization/82396] [8 Regression] qsort comparator non-negative on sorted output: 4 in ready_sort_real in haifa scheduler

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82396 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #11

[Bug target/81356] __builtin_strcpy is not good for copying an empty string on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81356 --- Comment #6 from Qing Zhao --- just found that a similar fix have been submitted 2 weeks ago to gcc_patches: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg173652.html

[Bug target/81356] __builtin_strcpy is not good for copying an empty string on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81356 --- Comment #5 from Qing Zhao --- the following code in config/aarch64/aarch64.c cause such behavior: 14143 static bool 14144 aarch64_use_by_pieces_infrastructure_p (unsigned HOST_WIDE_INT size, 14145

[Bug target/81356] __builtin_strcpy is not good for copying an empty string on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81356 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #4

[Bug target/81357] Extra mov for zero extend of add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 --- Comment #13 from Qing Zhao --- I checked the same testing case on X86, SPARC in addition to aarch64, all have the same issue: (compile with gcc -O, the default is -m64) ***x86: test1: .LFB0: .cfi_startproc leal1(%rdi),

[Bug target/81357] Extra mov for zero extend of add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 --- Comment #12 from Qing Zhao --- > Well it is not wrong, just non-optimal. It is possible to use a single > register > here but it means teaching GCC that these values are identical, which is > non-trivial as it likely affects various places

[Bug target/81357] Extra mov for zero extend of add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 --- Comment #10 from Qing Zhao --- the following is my conclusion on this bug based on previous discussion and study, for this testing case: 1. due to the fact that "mov" and "uxtw" are the same instruction, the assembly generated by -O1 and

[Bug target/81357] Extra mov for zero extend of add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 --- Comment #8 from Qing Zhao --- > > I don't think there is an easy fix for this example. The compiler believes > there are 2 distinct values so it uses 2 registers irrespectively of the order > of the mov and uxtw. then, why when there is NO

[Bug target/81357] Extra mov for zero extend of add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 --- Comment #5 from Qing Zhao --- Hi, wilco, thanks for the comments. see me reply below: > On Sep 28, 2017, at 2:13 PM, wilco at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 > >

[Bug target/81357] Extra mov for zero extend of add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 --- Comment #3 from Qing Zhao --- the zero extension "uxtw" insn is generated even without any optimiation, the additional "mov" insn generated in -O2 is introduced by -fschedule-insns, please see the following:

[Bug target/81357] Extra mov for zero extend of add

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81357 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #1

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80266 --- Comment #5 from Qing Zhao --- Okay, will let you know when the patch is put into upstream. Qing > On Sep 26, 2017, at 5:56 AM, wilco at gcc dot gnu.org > wrote: > >

[Bug target/80266] ICE in store_pairsi condition with -mabi=ilp32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80266 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #3

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 --- Comment #4 from Qing Zhao --- working on a fix to this bug. let me know if you are working on it too.

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #3

[Bug target/81422] [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81422 --- Comment #3 from Qing Zhao --- if the DEST is NOT a REG (sometimes it's a SUBREG, for example in the testing case of this Bug), the REG_EQUIV notes should NOT be added.

[Bug target/81422] [aarch64] internal compiler error: in update_equiv_regs, at ira.c:3425

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81422 Qing Zhao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #2

[Bug target/81800] [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800 --- Comment #4 from Qing Zhao --- since I cannot change the Assignee field, in order to avoid redundant work: I am currently studying this bug and try to fix it.

[Bug target/81800] [8 regression] on aarch64 ilp32 lrint should not be inlined as two instructions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800 --- Comment #3 from Qing Zhao --- I can repeat this with the latest upstream gcc on aarch64 machine. the inlining happens when -fno-math-errno is specified. and it should be only inlined when -fno-trapping-math is specified.