https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
: 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=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
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
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&action=edit
tar file that can repeat the
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=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
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 str
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
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), th
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
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 on
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
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;
>
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
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
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
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 i
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
>
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 docu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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 {
> &g
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,
&g
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 mandato
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 se
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
> (
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 sho
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;
>
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 ext
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 te
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 (Linu
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 m
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
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 ne
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
--- Comment #8 from qinzhao at gcc dot gnu.org ---
fixed in gcc11 too.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
During my work on updating array_at_struct_end_p with the new
-fstrict-flex-array control, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status
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
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 &qu
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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), th
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever
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 t
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
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
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
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-
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 ab
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.
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=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
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
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #3 from qinzhao at gcc dot gnu.org ---
the root cause for this bug is due to the new call to __builtin_clear_padding
added by -ftrivial-auto-var-init=pattern, this is treated as a use of the
uninitialized variable during early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #6)
> > --- Comment #4 from Andrew Pinski ---
> > Maybe __builtin_clear_padding lowering should mark the load "MEM[(struct
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Well, for the .DEFERRED_INIT case if the var ends up in memory, I really
> don't see the point in any clear_padding, .DEFERRED_INIT expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #10)
> Even in that case, filling the memory with pattern & mask instead of filling
> the memory with pattern + __builtin_clear_padding afterw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
--- Comment #14 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
> and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also
> avoid warnings on:
> 1) call to .DEFERRED_INIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103038
--- Comment #6 from qinzhao at gcc dot gnu.org ---
just wondering why the ICE after my fix to PR102281. and found the reason:
Before the fix to PR102281, the IR before expansion phase is:
void test ()
{
<<< Unknown tree: of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103025
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033
--- Comment #2 from qinzhao at gcc dot gnu.org ---
I can repeat this ICE on the gcc farm machine gcc112, which is a Powerpcle
linux machine with the latest upstream gcc (11/2/2021).
and locate the issue at:
Breakpoint 2, expand_DEFERRED_INIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127
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=103127
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #5)
> (In reply to qinzhao from comment #4)
> > with -ftrivial-auto-var-init=zero, failed at the same place.
>
> You mean without the pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103127
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > The types are OPAQUE_TYPE.
> [snip]
> > So if I understand this correctly and PR 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103206
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=103271
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=103127
--- Comment #11 from qinzhao at gcc dot gnu.org ---
Please see the details of the discussion of the patch for this bug:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg275509.html
as a summary, we decide to exclude OPAQUE_TYPE from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #8 from qinzhao at gcc dot gnu.org ---
the minimum option to repeat this failure is "-O1 -mno-strict-align".
The option "-mno-strict-align" is the one that make the difference.
For the following call to .DEFERR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #9 from qinzhao at gcc dot gnu.org ---
disable tree-ccp by adding -fno-tree-ccp cures the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #10 from qinzhao at gcc dot gnu.org ---
looks like that this is exactly the same issue as exposed in pr102285.
and the original fix to pr102285 just hide this inconsistent IR issue.
-mno-strict-align exposed this issue again.
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #15 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #11)
>
> I suppose assigning TImode to a decl but not even being able to move TImode
> can be a problem elsewhere...
this might be the root i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103271
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #12)
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 6ac3460d538..08f94b7a17a 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/i
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
There are multiple bogus warnings from -Wuninitialized +
-ftrivial-auto-var-init when building linux kernel the the latest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103720
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
>
> Dom transformed:
> c$a$0_6 = .DEFERRED_INIT (8, 2, 0);
> _1 = .DEFERRED_INIT (8, 2, 0);
>
> into:
> c$a$0_6 = .D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102269
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=102273
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=102285
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=102285
--- Comment #2 from qinzhao at gcc dot gnu.org ---
I checked all the listed testing cases with the latest GCC + -g
-ftrivial-auto-var-init=pattern -O2
all passed without issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #5 from qinzhao at gcc dot gnu.org ---
with the latest GCC, for all the 42647 c files under gcc/testsuite, with -c -g
-O2 -Wall -ftrivial-auto-var-init=zero, there is only one failure:
/home/opc/Install/latest/bin/gcc -c -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot
101 - 200 of 390 matches
Mail list logo
