https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99328
Bug ID: 99328
Summary: ICE: in verify_target_availability, at
sel-sched.c:1557 with -fselective-scheduling2 on
aarch64
Product: gcc
Version: 11.0
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99332
Bug ID: 99332
Summary: ICE:inreset_sched_cycles_in_current_ebb, at
sel-sched.c:7147 with -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2
-fsel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421
Bug ID: 99421
Summary: ICE:in code_motion_process_successors, at
sel-sched.c:6389 on aarch64
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421
--- Comment #2 from qinzhao at gcc dot gnu.org ---
Created attachment 50318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50318&action=edit
tar ball to repeat the failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99421
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #3)
> Confirmed, reduced test-case:
>
just curious, how did you reduce the testing case with -fprofile-use? (I tried
Creduce, but failed)
another question, h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99627
Bug ID: 99627
Summary: ICE:in sel_is_loop_preheader_p, at sel-sched-ir.c:6347
with -fprofile-use -fselective-scheduling
-fsel-sched-pipelining
-fsel-sched-pipelinin
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&action=edit
testing case and script
testing case and script
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=100053
Bug ID: 100053
Summary: tree-fre incorrectly delete a condition
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> It would be nice if the reduced testcase could be sanitized to throw less
> diagnostics with -Wall, likewise if it were a runtime testcase.
>
> Red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100053
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Created attachment 50579 [details]
> fix for the issue
>
> I am testing this patch - maybe you can test it on the original testcase you
> cannot d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97357
Bug ID: 97357
Summary: Unable to coalesce ssa_names which are marked as MUST
COALESCE.
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
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/10.2
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=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 errors are all like thi
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 fixed b
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=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 is not recogniz
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, command line option
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_80387 ? FLOAT_REGS : NO_REGS"
>
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 not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97715
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 the n
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.c b/gcc/reg-stack.c
i
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 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97309
Bug ID: 97309
Summary: Improve documentation of -fallow-store-data-races
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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 --g
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=97309
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98702
Bug ID: 98702
Summary: linker failure with a very simple testing case for
gcc10
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Prio
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/mingw/include/minwindef.h:163,
>
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=101832
--- Comment #7 from qinzhao at gcc dot gnu.org ---
from the standard:
A structure or union shall not contain a member with incomplete or function
type (hence, a structure shall not contain an instance of itself, but may
contain a pointer to an i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
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=107952
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> GCC considered this as a flex-array.
do you mean for the following example:
typedef struct {
char pad;
char data[];
} F2;
typedef struct {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #16)
> > We might add a new utility routine to determine whether a ref to a struct or
> > union have flexible array?
>
> It will be useful for __bos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> This is intentional, if you embed an aggregate with flex array into another
> struct and ask not to cross the field boundaries (i.e. bos1), then the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #9 from qinzhao at gcc dot gnu.org ---
I will add a routine in tree-object-size.cc to check whether a reference to a
structure or union field includes a flexible array member in the inner
structure, such structure or union should be c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107952
--- Comment #19 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #11)
> > Agreed, usually where these extension should be documented?
>
> They are usually documented in doc/extend.texi
there is one section on "Ze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #10 from qinzhao at gcc dot gnu.org ---
shall we support the following multi-level nesting?
struct A { int len; char data[]; };
struct B { int n; struct A a; };
struct C { int m, struct B b; };
struct C *outer;
__builtin_object_siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
>
> The gimplifier instead of
>
> _1 = t ();
> D.2389 = _1;
> e = &D.2389;
> _2 = *e;
> f (_2);
>
> produces
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #9 from qinzhao at gcc dot gnu.org ---
it's a bug in tree-ssa-uninit.cc actually.
when doing the following:
/* Ignore the call to .DEFERRED_INIT that define the original
var itself as the following case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #10 from qinzhao at gcc dot gnu.org ---
the following patch fixed this issue:
diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index c555cf5cd50..eca727b010a 100644
--- a/gcc/tree-ssa-uninit.cc
+++ b/gcc/tree-ssa-uninit.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to qinzhao from comment #10)
> > the following patch fixed this issue:
>
> This would leak memory.
thank you, I will fix the memory lea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
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=108894
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Well, -fsanitize=bounds-strict certainly shouldn't imply
> -fstrict-flex-arrays=2,
> it should just treat [1] and [4] (but I think it does even [0] r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)
> I'd keep its current behavior, perhaps except for -fsanitize=bounds-strict
> -fstrict-flex-arrays{,=3} so that -fsanitize=bounds
> -fstrict-flex-a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #13 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #12)
> Created attachment 54547 [details]
> gcc13-pr108894.patch
>
> Untested fix.
several comments on the patch:
1. should the documentation of -fsani
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 107411, which changed state.
Bug 107411 Summary: trivial-auto-var-init=zero invalid uninitialized variable
warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Richard Biener from comment #2)
> > Iff only (GNU) C would accept the following ...
> >
> > struct foo {
> > ...
> > unsigned i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #7)
> An attribute is certainly simpler and should be easy to add.
yes.
>
> I proposed similar extension for C23 and there was some interest,
> but I did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
>
> https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
thanks for the info.
>
> But we made variably modified types mandatory in C23 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
>
> Here, we want to use a member of the struct as a size
> expression. This could work equally at function and file scope.
> But the semantics need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #23 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #13)
>
> VLAs and VM types exist since C99 and were made optional in C11.
> The minimal change we adopted to make support for VM types
> (but not VLAs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #24 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #15)
>
> Yes, but that syntax would be intuitive which I would see
> as an advantage.
Yes, I agree.
>
> But I am not saying we shouldn't have the attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #25 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #17)
> The syntax with the dot would make it not conflict. But I need
> this for this use case
>
> struct foo {
> int count;
> int (*buf)[.count];
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #26 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #20)
>
> I agree. An attribute is simple and extending C will take
> more care (and work).
>
> The reason I think we should also extend C (together with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #27 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #22)
> This really should have been the way __access__ was implemented, but we tied
> that attribute to only functions. Would it be a terrible idea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #30 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #28)
> The problems with VLA are in my opinion caused by poor
> implementation (e.g. no stack probing etc) and bad
> code generation (Linus was not happy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #31 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #29)
> > however, I think that both the new attribute and the new C syntax extension
> > should support the similar user interface. We might need to decid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #33 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #32)
> > > > struct foo {
> > > > int len;
> > > > char (*buf)[.len];
> > > > };
> Here the last element is not a flexible array member but
> a point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
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=104550
--- Comment #17 from qinzhao at gcc dot gnu.org ---
So, based on the discussion so far, I'd like to take the following steps:
1. In GCC12, I will take a conservative solution to fix this bug, i.e:
mark the load "MEM" as not needing a warning du
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #18 from qinzhao at gcc dot gnu.org ---
One question here, for the following testing case:
[opc@qinzhao-ol7u9 104550]$ cat t1.c
struct vx_audio_level {
int has_monitor_level : 1;
};
void vx_set_monitor_level() {
struct vx_audio_le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #8 from qinzhao at gcc dot gnu.org ---
fixed in gcc11 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
Bug ID: 106457
Summary: array_at_struct_end_p returns TRUE for a two-dimension
array which is not inside any structure
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #5 from qinzhao at gcc dot gnu.org ---
I am wondering whether the following:
12781 /* If the object itself is the array it is not at struct end. */
12782 if (DECL_P (ref_to_array))
12783 return false;
should be:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #6 from qinzhao at gcc dot gnu.org ---
the following patch fixed the issue:
[opc@qinzhao-aarch64-ol8 gcc]$ git diff tree.cc
diff --git a/gcc/tree.cc b/gcc/tree.cc
index fed1434d141d..d04ac121765a 100644
--- a/gcc/tree.cc
+++ b/gcc/tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #7 from qinzhao at gcc dot gnu.org ---
another testing case failed with the current "array_at_struct_end_p":
gcc/testsuite/gcc.target/aarch64/vadd_reduc-2.c
1 /* { dg-do compile } */
2 /* { dg-additional-options "-O3 -std=c99" } *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #8 from qinzhao at gcc dot gnu.org ---
another testing case failed with the current array_at_struct_end_p is:
gcc/testsuite/gcc.dg/torture/pr50067-1.c:
1 /* { dg-do run } */
2
3 /* Make sure data-dependence analysis does not co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
--- Comment #9 from qinzhao at gcc dot gnu.org ---
one more testing case failed with the current array_at_struct_end_p
is:gcc/testsuite/gcc.dg/torture/pr50067-2.c:
1 /* { dg-do run } */
2
3 /* Make sure data-dependence analysis does not co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|RE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> This is intentional, if you embed an aggregate with flex array into another
> struct and ask not to cross the field boundaries (i.e. bos1), then the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
--- Comment #3 from qinzhao at gcc dot gnu.org ---
this is fixed with the following commit in gcc12.
https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359118.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #2 from qinzhao at gcc dot gnu.org ---
This is a bug in pass_zero_call_used_regs, when updating df after the zeroing
sequence is added in the epilogue of the function, we should call
"df_update_exit_block_uses" to update the reg use i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #3 from qinzhao at gcc dot gnu.org ---
the following simple patch resolved the issue:
diff --git a/gcc/function.cc b/gcc/function.cc
index e1d2565f8d9..c8a77c9a624 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -5942,6 +5942,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-01-28
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
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=101515
--- Comment #5 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is:
1. there is no NAME for the pointer to member function type as the following:
(in cp/decl.cc)
tree
build_ptrmemfunc_type (tree type)
{
10655 finish_builti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
--- Comment #6 from qinzhao at gcc dot gnu.org ---
the following patch fixed this bug:
[opc@qinzhao-aarch64-ol8 latest_gcc]$ git diff
diff --git a/gcc/cp/cxx-pretty-print.cc b/gcc/cp/cxx-pretty-print.cc
index 4f9a090e520d..744ed0add5ba 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #5 from qinzhao at gcc dot gnu.org ---
fixed in gcc12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
--- Comment #7 from qinzhao at gcc dot gnu.org ---
for the following IR:
struct sp x;
void (*) (void) _1;
...
[local count: 1073741824]:
_1 = MEM[(struct ptrmemfunc_U *)&x].ptr;
_7 = _1 != 8B;
***Before commit r11-6729-gadb520606ce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586
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=102276
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> If we just want to avoid the warning in cases like that (there is nothing
> wrong in the testcases themselves, the warning just warns about an
> impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #9 from qinzhao at gcc dot gnu.org ---
having a patch in my local tree, under testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
Bug ID: 104550
Summary: bogus warning from -Wuninitialized +
-ftrivial-auto-var-init=pattern
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #1 from qinzhao at gcc dot gnu.org ---
Kees reported the following issue with -ftrivial-auto-var-init=pattern. the
testing case was reduced from Kernel building.
$ cat warns.i
struct vx_audio_level {
int has_monitor_level : 1;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-02-15
Ever confirm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #10)
> I think it definitely makes sense to diagnose that we are not
> following -ftrivial-auto-init-var=X for a decl. Maybe we should
> do that wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #12 from qinzhao at gcc dot gnu.org ---
I will go with the following solution:
1. avoid emitting switch-unreachable warnings for -ftrivial-auto-var-init;
2. adding a new option -Wtrivial-auto-var-init to emit warnings for the
switch-
1 - 100 of 318 matches
Mail list logo
