https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #11 from qinzhao at gcc dot gnu.org ---
please see discussion at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651482.html
A summary of the discussion:
1. The current warning is correct, which catches a potential source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #10 from qinzhao at gcc dot gnu.org ---
with the following added heuristic in array-bound checker:
+ /* If the stmt is duplicated and splitted, the warning level is not 2,
+ and the current block is not dominating the exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Version|unknown |15.0
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Kees Cook from comment #8)
> Normally -Warray-bounds doesn't warn when a value is totally unknown (i.e.
> "index" here can be [-INT_MAX,INT_MAX]). Why does the war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Kees Cook from comment #6)
> (In reply to qinzhao from comment #5)
> > adding __attribute__ ((noreturn)) to the routine "warn" can eliminate the
> &g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109071
--- Comment #5 from qinzhao at gcc dot gnu.org ---
adding __attribute__ ((noreturn)) to the routine "warn" can eliminate the false
positive warning.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53548
--- Comment #10 from qinzhao at gcc dot gnu.org ---
Clang has accept this extension:
https://github.com/llvm/llvm-project/pull/84428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817
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=53548
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=111523
--- Comment #10 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #9)
> Anways systemd has now changed the buffer to 256 which is much much smaller
> and for most calls enough in size before needing to real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #50 from qinzhao at gcc dot gnu.org ---
the 6th version of the patch sets targeted on GCC15 has been submitted to GCC
alias for review:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645838.html
https://gcc.gnu.org/pipermail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111523
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=111407
--- Comment #13 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #12)
> (In reply to qinzhao from comment #10)
> > (In reply to Andrew Pinski from comment #6)
> > the fix has been in GCC14, shall we bac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #10 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #6)
the fix has been in GCC14, shall we backport the patch to previous releases?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #8 from qinzhao at gcc dot gnu.org ---
the latest GCC14 has the same issue.
with the patch proposed in comment #1, the failure has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #5)
> Testcase:
thanks a lot for the testing case. GCC8 failed with this, disable
tree-widening_mul fixed the failure.
and my patch for GCC8 also fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> Also what target is this for?
> I suspect aarch64 since x86_64 does not have widening multiply ...
you are right, it's aarch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> Do you have a testcase?
I have, but I cannot expose it to public.
I can provide the Bad IR and Good IR if you think it's okay.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
this bug was originally reported against GCC8.5 with profiling feedback.
there were multiple similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Kees Cook from comment #11)
> The trouble with "optimize" is that it just doesn't work. The kernel has
> banned its use because it results in all other optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
--- Comment #3 from qinzhao at gcc dot gnu.org ---
a summary of the discussion:
We have two different sources to get the size information for subobjects:
A. The TYPE information of the subobject in the IR;
B. The initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
--- Comment #2 from qinzhao at gcc dot gnu.org ---
the discussion on this bug is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627631.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
--- Comment #1 from qinzhao at gcc dot gnu.org ---
an initial study inside gdb shows the following:
1. the guilty pass is "ccp1", when folding the call to
__builtin_dynamic_object_size(p->array, 1)
2. In this pass, the IR
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
__bos produces different results for subobject with different optimizations:
#include
#include
#define
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
current __builtin_dynamic_object_size cannot handle VLA correctly for the
sub-object size, please see the following testing case:
#include
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #14 from qinzhao at gcc dot gnu.org ---
since it's opened again GCC12, the patch need to be backported to GCC12. then
will be closed at that time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #13 from qinzhao at gcc dot gnu.org ---
the fix has been committed into GCC14.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #8 from qinzhao at gcc dot gnu.org ---
with the following slightly modified testing case, the same issue:
#include
#include
struct P {
int k;
int x[10];
} *p;
void store(int a, int b)
{
p = (struct P *)malloc (sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #8 from qinzhao at gcc dot gnu.org ---
for record purpose, the code in glibc has already been fixed.
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611220.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101832
--- Comment #11 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 bounda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #7 from qinzhao at gcc dot gnu.org ---
the patch for this documentation change in GCC has been posted and approved
at:https://gcc.gnu.org/pipermail/gcc-patches/2023-May/620148.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #45 from qinzhao at gcc dot gnu.org ---
the first version of the patches were submitted to upstream today for
discussion:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619708.html
https://gcc.gnu.org/pipermail/gcc-patches/2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #44 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #43)
> works with the bounds checking code? Does it also interact with the object
> size pass?
both array-bounds sanitizer and object siz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #41 from qinzhao at gcc dot gnu.org ---
my private gcc is able to use the element_count information in bound sanitizer
now:
[opc@qinzhao-ol8u3-x86 108896]$ cat t6.c
#include
#include
struct P {
int k;
int x[] __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #7 from qinzhao at gcc dot gnu.org ---
Okay, thanks for the comment. I see why this should not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #40 from qinzhao at gcc dot gnu.org ---
I had an initial patch to support the element_count attribute and use this
attribute in builtin_dynamic_object_size(), for the following testing case:
1 #include
2 #include
3 #ifdef
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
during my work for PR108896, I found that for the following small testing case:
[opc@qinzhao-ol8u3-x86 108896]$ cat test.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #39 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #38)
> struct foo {
>int n;
>char (*buf)[.n];
> };
>
> void store(struct foo* p, int a, int b) { (*p->buf)[a]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #37 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #36)
>
> I considered pointers to arrays:
>
> struct P {
> int n;
> char (*buf)[.n];
> };
>
Okay.
Then for the field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #35 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #34)
> Created attachment 54787 [details]
> patch for C FE to add size expressions to VM types in structs
thanks a lot for the patch.
could you
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=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];
> > > > };
> H
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. W
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 generati
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 #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 #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 #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
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 #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 #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 mand
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 #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=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
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=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 d
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
> -fst
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 doe
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=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=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 #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 #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 =
> _2 = *e;
> f (_2);
>
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=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
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
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
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?
>
>
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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #43 from qinzhao at gcc dot gnu.org ---
the related patch list for this work is (gcc13)
2a27ae32fabf85685758459d7ec284ccb95a
710c9676520dfd38b4bfdcc937ce026ed89921d6
ace0ae09332bbc6b95e084c2c2b17c466339ff76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94428
--- Comment #4 from qinzhao at gcc dot gnu.org ---
a new warning -Wstrict-flex-arrays was added to gcc13.
when using -Wstrict-flex-arrays -fstrict-flex-arrays=3 together, the new
warning will report any misuse of zero-length arrays as flexible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-12-15
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132
--- Comment #1 from qinzhao at gcc dot gnu.org ---
As we checked the assembly and the IR, the wrong transformation is something
like the following at source code level: (inside function "main")
from :
a=f(a);
Severity: major
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
The error only happens on aarch64 (fine on X86).
The following testing case:
[opc@qinzhao-aarch64-ol8]$ cat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #7)
>
> Because after all those years, you don't really know if it is just glibc
> (which likely doesn't do that anymore), but many other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
--- Comment #6 from qinzhao at gcc dot gnu.org ---
after reading the history, my understanding is:
this gcc extension is added as a workaround to build glibc since glibc source
code has such usage of flexible array members;
my question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107951
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=106123
--- Comment #3 from qinzhao at gcc dot gnu.org ---
the minimized testing case:
struct S { int t; int a; void foo (); };
void
S::foo ()
{
#pragma omp parallel
{
#pragma omp taskloop firstprivate (a)
for (int i = 0; i < a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106123
--- Comment #2 from qinzhao at gcc dot gnu.org ---
simplified testing case:
[opc@qinzhao-ol8u3-x86 106123]$ cat t.C
struct T { T () {}; virtual ~T () {}; int t; };
struct S : virtual public T { int a; void foo (); };
template
struct U { U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
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=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
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 #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
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
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 #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 #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status
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=106270
--- Comment #1 from qinzhao at gcc dot gnu.org ---
from Jose Marchesi:
We looked at this issue and these are our findings.
- When this problem happens:
When the linker (ld) fails to insert a veneer (that transforms the
immediate bl
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
Created attachment 53291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53291=edit
tar ball for the sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #39 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #23)
> Also I wonder if there should be an analogous -Wstrict-flex-arrays to issue
> warnings alongside changing codegen.
please take
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #38 from qinzhao at gcc dot gnu.org ---
(In reply to James Y Knight from comment #37)
> (In reply to qinzhao from comment #35)
> > I think that -Wstrict-flex-arrays will need to be cooperated with
> > -fstrict-fle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #35 from qinzhao at gcc dot gnu.org ---
(In reply to James Y Knight from comment #33)
>
> I don't understand what the -Wstrict-flex-arrays warning and its multiple
> levels is proposed to actually do.
>
> Is it s
1 - 100 of 304 matches
Mail list logo
