https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 83026, which changed state.
Bug 83026 Summary: missing strlen optimization for strcmp of unequal strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #46 from qinzhao at gcc dot gnu.org ---
https://gcc.gnu.org/viewcvs/gcc?view=revision=263028
was to fix the optimization level issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #17 from qinzhao at gcc dot gnu.org ---
the patch has been committed as:
https://gcc.gnu.org/viewcvs/gcc?view=revision=263563
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #14 from qinzhao at gcc dot gnu.org ---
reported by christophe.l...@linaro.org:
After this change,(disable strcmp/strncmp inlining with O2 below and Os), I've
noticed that:
FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #16 from qinzhao at gcc dot gnu.org ---
please test the proposed patch on your platform, let me know the result.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #15 from qinzhao at gcc dot gnu.org ---
Created attachment 44516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44516=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #19 from qinzhao at gcc dot gnu.org ---
which sparc machine was used to repeat the failure, and what's the configure
and make options?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64949
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #7 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is:
for the following call to memcmp: __builtin_memcmp (s->s, "a", 3);
the specified length 3 is larger than the length of "a", it's clearl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #42 from qinzhao at gcc dot gnu.org ---
just checked in the patch for fixing the unsigned char issue as:
https://gcc.gnu.org/viewcvs/gcc?view=revision=262907
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #1 from qinzhao at gcc dot gnu.org ---
I cannot repeat this issue on a powerPc machine:
Native configuration is powerpc64-unknown-linux-gnu
=== gcc tests ===
Schedule of variations:
unix
Running target unix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
from Martin Sebor:
an enhancement to this optimization implemented for 78809 that might
be worth considering is inlining even non-constant calls
with array arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #36 from qinzhao at gcc dot gnu.org ---
the 3rd part (the last part) of this PR was checked into GCC 9 today as:
https://gcc.gnu.org/viewcvs/gcc?view=revision=262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #37 from qinzhao at gcc dot gnu.org ---
since all the implementation were in trunk.
can I close this PR now?
: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
currently, -fopt-info-inline does not report any info from early inliner.
for example:
[qinzhao@localhost inline_report]$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #47 from qinzhao at gcc dot gnu.org ---
all the issues triggered by the previous patch have been fixed.
I am planing to close this PR as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #21 from qinzhao at gcc dot gnu.org ---
the latest patch to this test bug has just been checked in at:
https://gcc.gnu.org/viewcvs/gcc?view=revision=263983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957
--- Comment #6 from qinzhao at gcc dot gnu.org ---
Author: qinzhao
Date: Wed Sep 26 22:29:54 2018
New Revision: 264657
URL: https://gcc.gnu.org/viewcvs?rev=264657=gcc=rev
Log:
2018-09-26 Indu Bhagat
PR gcov-profile/86957
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89730
--- Comment #2 from qinzhao at gcc dot gnu.org ---
Author: qinzhao
Date: Wed Apr 3 19:00:25 2019
New Revision: 270134
URL: https://gcc.gnu.org/viewcvs?rev=270134=gcc=rev
Log:
2019-04-03 qing zhao
PR tree-optimization/89730
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
for the following small testing case:
extern int sum, n, m;
extern inline __attribute__
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
for some large complicate applications, sometimes the depth of nested #include
might be very big, exceeding the current hard-coded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed. Just curious - were you able to simply up this limit
> successfully?
Yes, one of our applications' depth of nested #include is 202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #24)
>
> > How about the patch for the above 2? has it been committed?
>
> It has been there for a while, please take a look at:
>
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
--- Comment #3 from qinzhao at gcc dot gnu.org ---
Author: qinzhao
Date: Tue Jul 2 20:23:30 2019
New Revision: 272948
URL: https://gcc.gnu.org/viewcvs?rev=272948=gcc=rev
Log:
PR preprocessor/90581
Add a cpp option -fmax-include-depth to set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832
--- Comment #6 from qinzhao at gcc dot gnu.org ---
one question to Martin:
has the proposed patch been committed in gcc9 upstream?
my understanding is the proposed patch is for LLVM source base, not for GCC.
are you planning to port the patch
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
we noticed that the profile directory will be concatenated with object file
path.
the following small example
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
GCC cannot compile the following small testing case:
[qinzhao@localhost]$ cat t1.c
extern void boo (void *addr);
#define foo(addr) \
boo (addr)
#define bar(instr, addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Joseph S. Myers from comment #1)
> This is not a bug in GCC, it's how the preprocessor is defined to work.
So, this is an user error? is there any C language rules on this?
why
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #5)
> We're talking about the sequence of pp-tokens in the expansion of bar(foo,
> addr), which is (foo) (addr), where foo is fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #3)
> Macro replacement for function-like macros is defined in C17 6.10.3.
> Note in paragraph 10 the words "the function-like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> Why is this a major issue? Just variable shadowing, so something that with
> -Wshadow* compiler will warn, but nothing more, the code i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382
--- Comment #7 from qinzhao at gcc dot gnu.org ---
I have just created a bug to record the debugging issue:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92386
(In reply to Jakub Jelinek from comment #6)
> Feel free to open an issue against
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gdb cannot print the correct value of variables if it's shadowed.
please see the following small testing case for an example:
1 #include
2 int
3 main ()
4 {
5 volatile int v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92382
--- Comment #5 from qinzhao at gcc dot gnu.org ---
Okay, I see. thank you for explanation.
I will close this one as not a bug.
(In reply to Jakub Jelinek from comment #4)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
In the routine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971
--- Comment #5 from qinzhao at gcc dot gnu.org ---
Author: qinzhao
Date: Wed Oct 23 18:12:39 2019
New Revision: 277344
URL: https://gcc.gnu.org/viewcvs?rev=277344=gcc=rev
Log:
2019-10-23 qing zhao
PR gcov-profile/91971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #2)
> Confirmed. Can you please send the patch to mailing list?
I have sent the patch to gcc-patches several weeks ago, and pinged twice
already:
ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971
--- Comment #1 from qinzhao at gcc dot gnu.org ---
the following simple patch will fix this issue:
$ git diff coverage.c
diff --git a/gcc/coverage.c b/gcc/coverage.c
index 0d5138f..a80337e 100644
--- a/gcc/coverage.c
+++ b/gcc/coverage.c
: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
Valgrind reported 12 memory errors when I run the latest upstream gcc with -O2
on the following small testing case:
[qinzhao@localhost memory_leak]$ cat t1.c
int main(int argc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832
--- Comment #11 from qinzhao at gcc dot gnu.org ---
Hi, (In reply to Martin Liška from comment #10)
> Fixed on trunk.
I am trying to back port the fix for 89832 into our company's gcc8.2.1 release.
by looking at the patch, it's huge, and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #6)
> If you have a huge workload, one possible workaround would be to disable
> range tracking, perhaps tweaking line_table->default_range_bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91203
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #6)
> If you have a huge workload, one possible workaround would be to disable
> range tracking, perhaps tweaking line_table->default_range_bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94855
--- Comment #1 from qinzhao at gcc dot gnu.org ---
this is a request to provide a new option in GCC to initialize automatic
variables for security purpose.
Motivations for this request:
1. Kees Cook's slide:
https://outflux.net/slides/2019/lca
: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Version|10.0|11.0
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87210
--- Comment #6 from qinzhao at gcc dot gnu.org ---
So, based on the previous discussion on the LLVM option
-ftrivial-auto-var-init=[uninitialized|pattern|zero]
we can see:
-ftrivial-auto-var-init=pattern
might not be a good idea due
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gcc issues the following warning message for -Wmisleading-indentation:
test.c:632: note: -Wmisleading-indentation is disabled from
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gcc issues the following warning message for -Wmisleading-indentation:
test.c:632: note: -Wmisleading-indentation is disabled from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> The size limitation is given from the way columns, lines, blocks and
> location ranges are encoded in location_t, which is a 32-bit number.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> We do not want to use 64-bit number for that, it is used everywhere in the
> compiler and would cause massive growth of compile time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #2)
> Thank you for the report. It's a known limitation Honza noticed me about.
> Is the size problematic from size perspective or speed perspecti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #4)>
> Can you please share some statistics how big are the files and how many runs
> do you merge?
There were on the order of 10,000 processe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #7)
> 1) You should not generate profile data for each process to a different
> folder, but rather merge it.
not sure how to do this? can you provid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #15 from qinzhao at gcc dot gnu.org ---
please refer to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #6
> Which means one run takes 100MB is size, right? As you mentioned, having
> 1000 .gcda files, it means that one takes 0.1MB?
around 14000 pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #18 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #16)
> > For our application, all processes generating profiling feedback data to a
> > single directory seems is not a choice.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #6)
more details:
>
> Which means one run takes 100MB is size, right? As you mentioned, having
> 1000 .gcda files, it means that one ta
: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
when using GCC and ICC to build a big parallel application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #24 from qinzhao at gcc dot gnu.org ---
with the patch added to gcc11, I tested it with the small testing case, and got
the following data:
**without the patch:
qinzhao@gcc14:~/Bugs/profile/small_gcc/gcc_prof_dir/13248$ ls -l
-rw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #36 from qinzhao at gcc dot gnu.org ---
I found a bug with this proposed patch:
when doing automatic merging, the following error message is emitted:
Merge mismatch for function 1.
the bug can be repeated with the small testing case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #37 from qinzhao at gcc dot gnu.org ---
So, the previous prof data size for the real application might not be correct.
After this bug is fixed, we might need to collect the new real code size
reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
--- Comment #39 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #38)
> Created attachment 48738 [details]
> Patch candidate v2
I have added this patch to my private gcc 8 with some change, works fine with
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #6 from qinzhao at gcc dot gnu.org ---
when using gcc10.2 to compile our application, we have the same compilation
error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
--- Comment #1 from qinzhao at gcc dot gnu.org ---
/home/qinzhao/Install/latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/qinzhao/Install/latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/qinzhao/Install/latest/libexec/gcc/x86_64-pc-linux-gnu
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
the latest gcc10.2.1 failed with SSA corruption on multiple c modules of our
important application on O3. disabling -fsplit-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #7 from qinzhao at gcc dot gnu.org ---
as we noticed, when using gcc10.2.1 compile our application, 528 C++ modules
failed with this bug.
looks like a high priority bug to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
--- Comment #9 from qinzhao at gcc dot gnu.org ---
with the patch, all the C modules in our application that failed with this bug
passed without any issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
--- Comment #1 from qinzhao at gcc dot gnu.org ---
proposed patch:
Subject: [PATCH] PR97309--improve documentation of -fallow-store-data-races
---
gcc/doc/invoke.texi | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff
: other
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
As of GCC 10, the former --param allow-store-data-races is now
-fallow-store-data-races. The default, in both cases, is not to allow them.
For releases prior to GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #3 from qinzhao at gcc dot gnu.org ---
This does not look like a bug in the new -fzero-call-used-regs implemenation.
it's more likely an existing bug in data flow analysis.
I made the following change in gcc/function.c to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #4 from qinzhao at gcc dot gnu.org ---
this should be a bug in the pass "stack".
if I modify the file "reg-stack.c" as following:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #5 from qinzhao at gcc dot gnu.org ---
the following patch in reg-stack.c fixed the failure:
qinzhao@gcc10:~/Work/write_gcc/gcc$ git diff reg-stack.c
diff --git a/gcc/reg-stack.c b/gcc/reg-stack.c
index 8f98bd85750..3dab843f803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
--- Comment #1 from qinzhao at gcc dot gnu.org ---
(In reply to seurer from comment #0)
> commit d10f3e900b0377b4760a090b0f90371bcef01686
> Author: qing zhao
> Date: Fri Oct 30 20:41:38 2020 +0100
>
> If looks like the erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97699
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> Err, please dg-skip the tests for ! supported targets. They also fail on
> x86_64 with -m32 btw.
x86_64 with -m32 failure should be already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #22 from qinzhao at gcc dot gnu.org ---
proposed patch:
This change fixes a bug in the i386 backend when adding
-fzero-call-used-regs=all on a target that has no x87
registers.
When there is no x87 registers available, we should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #1 from qinzhao at gcc dot gnu.org ---
for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
mode, However, command line option force no 80387 mode, the following insn
generated to zero st registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> ;; Floating-point register constraints.
> (define_register_constraint "f"
> "TARGET_80387 || TARGET_FLOAT_RETURNS_IN_8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #2)
> (In reply to qinzhao from comment #1)
> > for -fzero-call-used-regs=all, when zeroing st/mm registers under x87 exit
> > mode, However, comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
Created attachment 49980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49980=edit
tar file that can repeat the fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to David Malcolm from comment #15)
> where:
>
> (gdb) call inform (loc_a, "loc_a")
> In file included from
> /usr/i686-w64-mingw32/sys-root/ming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391
--- Comment #23 from qinzhao at gcc dot gnu.org ---
with the latest gcc11, our application can be compiled without any issue now.
thanks a lot for fixing this bug.
will this patch be added to gcc10?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
--- Comment #2 from qinzhao at gcc dot gnu.org ---
NOTE, this failure is on aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
--- Comment #1 from qinzhao at gcc dot gnu.org ---
Created attachment 50411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50411=edit
testing case and script
testing case and script
: qinzhao at gcc dot gnu.org
Target Milestone: ---
Another selective scheduler's bug with profiling feedback from CPU2017.
reduced testing case attached.
to reproduce:
download the *.tar.xz file;
untar it;
cd bug_4
sh t
qinzhao@gcc113:~/Bugs/bug_4$ sh t
during RTL pass: sched1
cfgloop.h
1 - 100 of 304 matches
Mail list logo
