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
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
> instrumented
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&action=edit
A.data
--- Comment #21 from Qing Zhao ---
Created attachment 48654
--> https://gcc.gnu.org/bugzilla/attachment.
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
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 w
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 #
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 lo
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
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
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&revision=255654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79538
Qing Zhao changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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
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
"s1
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 compa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
Qing Zhao changed:
What|Removed |Added
Attachment #42449|0 |1
is obsolete|
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 is
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 array
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&action=edit
code size impact from inlining str(n)cmp with different n on X86
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.
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 folder-base
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?
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 “unsigned
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
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 m
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 m
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.
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
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 his
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.
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.
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.
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.
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
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.
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
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.
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
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:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80266
>
> --- Comment #4 fr
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
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:
***/home/qinzhao/Install/latest/b
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
>
> --- Comment #4 from Wilco
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
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
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 i
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), %
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
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 unsi
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80295
--- Comment #7 from Qing Zhao ---
thank you, Wilco.
> Wilco changed:
>
> What|Removed |Added
>
> CC|
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&action=edit
proposed patch
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
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
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&action=edit
Run time performance testing case on aarch64
this is for testing the run-time performance of inlined version of str
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 th
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 null-termina
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
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 im
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 areas
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
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 __builtin_st
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
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
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
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.
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 won
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?
>
> Th
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
> +++ gcc/funct
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;
>>
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
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 (!fixed_regs[
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
aarch64
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
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 outer
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
>> “array_ref_flexi
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 a
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(&info) a REAL use
>> of "info"? is it correct to report the uninitialized use
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 initialization,
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 ()
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 *)&info]" as not needing a warning.
>
This sound
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 sto
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.
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 “ma
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 by
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 i
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
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, 3.0e
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)
>>
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.
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:
>>
>>
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
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 comm
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 defaul
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 t
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)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #25 from Qing Zhao ---
> --- Comment #24 from Martin Uecker ---
>
> A builtin that returns the name or an lvalue for the member would seem to be
> more useful, but then harder to ignore when there is no attribute.
You mean, instea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #27 from Qing Zhao ---
--- Comment #26 from Siddhesh Poyarekar ---
> (In reply to Qing Zhao from comment #25)
>> If (__builtin_get_counted_by (P->FAM))
>> __builtin_get_counted_by (P->FAM) = COUNT;
>
> Do we have language construc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116933
--- Comment #11 from Qing Zhao ---
> On Oct 4, 2024, at 14:03, ebotcazou at gcc dot gnu.org
> wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116933
>
> --- Comment #7 from Eric Botcazou ---
> Another installment in the series "How
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116933
--- Comment #18 from Qing Zhao ---
> On Oct 7, 2024, at 11:34, ebotcazou at gcc dot gnu.org
> wrote:
> I see, thanks for investigation! This was overlooked because the C family of
> compiler do not use the declaration built in common_builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585
--- Comment #7 from Qing Zhao ---
>
> Yes, I'll pick it up after some soaking on trunk during my next backporting
> round. If you want to do the work of cherry-picking and regtesting feel free
> to do this earlier - it's been a week on trunk a
100 matches
Mail list logo
