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
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 warning change when
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
> > false positive warning.
>
> But
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
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 reallocate the
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/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 backport the patch
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 fixed
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111407
Bug ID: 111407
Summary: ICE: SSA corruption due to widening_mul opt on
conflict across an abnormal edge
Product: gcc
Version: 14.0
Status: UNCONFIRMED
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 optimization options being
>
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 for p->array is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
Bug ID: 111040
Summary: __builtin_object_size: inconsistent result for
subobject with member arrays.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030
Bug ID: 111030
Summary: tree-object-size: incorrect sub-object size for VLA
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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 boundaries (i.e. bos1),
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/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 size pass are
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
Bug ID: 109557
Summary: __builtin_dynamic_object_size() does not work for
simple testing case
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
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] = b; }
>
> int main()
> {
>
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 "buf", it has a pointer
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 please
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];
> > > > };
> Here the last element is not a flexible array member but
> a
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
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
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
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
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 #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
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 #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 #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 #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 #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
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 documentation of
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 #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]
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 fix the memory
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
+++
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);
>
> produces
>
> _1 =
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 one section on
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=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=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
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
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 to an
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);
b=true;
to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108132
Bug ID: 108132
Summary: Wrong instruction scheduling around function call with
longjmp on aarch64 at O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
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 programs in the
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 is:
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; i++)
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. bos1), then the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106457
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
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
--- 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 #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 #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
+++
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 |---
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106270
Bug ID: 106270
Summary: [Aarch64] -mlong-calls should be provided on aarch64
for users with large applications
Product: gcc
Version: 13.0
Status: UNCONFIRMED
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 a look at
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-flex-arrays=N, i.e,
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 supposed to warn on
1 - 100 of 232 matches
Mail list logo