https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117375
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117375
--- Comment #7 from qinzhao at gcc dot gnu.org ---
The reason for the ICE is:
The destination of the code movement due to tree sinking might not be the
immediate destination block of the block in which the statement locates.
for example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117375
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Sam James from comment #3)
> btw, I haven't tried bootstrapping with -fdiagnostics-details, but it might
> be worth trying to bootstrap and regtest with a patch that does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117375
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=117179
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
--- Comment #13 from qinzhao at gcc dot gnu.org ---
>when adding -fno-tree-sink, the warning disappeared.
Before tree-sinking optimization, the IR is: (c.151t.pre)
[local count: 1073741824]:
c.0_1 = c;
_2 = c.0_1 + 1;
_5 = strlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117179
--- Comment #4 from qinzhao at gcc dot gnu.org ---
Looks like that my RFC patch currently has bugs that cannot locate the event
accurately.
need more study here to see how to locate the conditional event accurately.
I need to reduce this test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117180
--- Comment #3 from qinzhao at gcc dot gnu.org ---
Looks like that my RFC patch currently has bugs that cannot locate the event
accurately.
need more study here to see how to locate the conditional event accurately.
I need to reduce this test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115274
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=106762
--- Comment #5 from qinzhao at gcc dot gnu.org ---
with my work-in-progress patch + -fdiagnostics-explain-harder:
t_106762.c: In function ‘bug’:
t_106762.c:16:2: warning: ‘memset’ offset [0, 7] is out of the bounds [0, 0]
[-Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108770
--- Comment #3 from qinzhao at gcc dot gnu.org ---
With my patch for new option -fdiagnostics-explain-harder, the output is:
t_108770.c: In function ‘init’:
t_108770.c:10:13: warning: array subscript 2 is above array bounds of ‘const
char *[2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85788
--- Comment #5 from qinzhao at gcc dot gnu.org ---
with my current patch to PR109071, adding -fdiagnostics-explain-harder, with
an additional option -fno-tree-dominator-opts, the diagnostic becomes:
t_85788.c:5:3: warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85788
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Liška from comment #0)
> As seen, d == 0, thus 'for (; c; c = e)' never executes. It's combination of
> jump-threading and VRP that triggers the w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #28 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #27)
> Yes, I agree with Jeff.
> This looks like a similar issue as PR109071.
the patch that improve the diagnostic for PR109071 could also improve this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116519
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #3)
> The warning disappears after adding -fno-thread-jumps.
> looks like similar issue as PR109071
further study turned out that: although using -fno-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116735
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116984
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=116983
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=116933
--- Comment #16 from qinzhao at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #12)
> > We added one more argument for __builtin_clear_padding to distinguish
> > whether this call is for AUTO_INIT or not.
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116933
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=85788
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=106762
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=108770
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=116519
--- Comment #3 from qinzhao at gcc dot gnu.org ---
The warning disappears after adding -fno-thread-jumps.
looks like similar issue as PR109071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
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=116735
--- Comment #3 from qinzhao at gcc dot gnu.org ---
This is a bug when handling the counted_by attribute when the corresponding
field doesn't exist.
under such situation, in addition to issue error, we also need to remove the
added "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116736
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=116736
--- Comment #2 from qinzhao at gcc dot gnu.org ---
currently, the "counted_by" info is used in __builtin_dynamic_object_size and
bounds sanitizer. and expected to catch out-of-bounds access during runtime.
So, this is the expected behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
> Fixed on trunk sofar.
thanks a lot for fixing this so quick.
Will this patch be backported to older releases?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46073
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Joseph S. Myers from comment #5)
> It's doubtful that this is a bug. You could define __builtin_choose_expr so
> the unselected operand only needs to be a balanced tok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46073
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Severity|minor |normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46073
--- Comment #4 from qinzhao at gcc dot gnu.org ---
the adoption of the new builtin __builtin_get_counted_by (PR116016) depends on
fixing this PR.
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
This is bug we found with GCC8 for our very large application. and it can be
repeated till the trunk GCC. (I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116316
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> :13:6: warning: dereferencing type-punned pointer will break
> strict-aliasing rules [-Wstrict-aliasing]
>13 | *(size_t *)(&(ar
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
the following testing case failed on both x86 and aarch64 with -O2, but passed
with -O1:
#include
struct annotated {
int b;
int c[];
} *array_annotated;
int main(int argc, char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #61 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #60)
> I came up with the following draft for the documentation of the new
> __builtin_get_counted_by, let me know your comments and suggestions:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #60 from qinzhao at gcc dot gnu.org ---
I came up with the following draft for the documentation of the new
__builtin_get_counted_by, let me know your comments and suggestions:
Builtin-in Function: type __builtin_get_counted_by (ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #56 from qinzhao at gcc dot gnu.org ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659478.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #52 from qinzhao at gcc dot gnu.org ---
(In reply to Alejandro Colomar from comment #51)
> I would make it a compile-time error. Why would we want to allow a non-FAM
> there? (Unless the [[gnu::counted_by()]] attribute makes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116155
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Dimitar Dimitrov from comment #11)
>
> With that change, the test passes for both x86 and pru.
thank you for the testing. could you please prepare the patch for this and
sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116155
--- Comment #10 from qinzhao at gcc dot gnu.org ---
(In reply to Dimitar Dimitrov from comment #9)
> For pru:
> sizeof (int) = 4
> __alignof__ (int) = 1
>
> From gcc/config/pru.h:
> #define INT_TYPE_SIZE 32
> #defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #48 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #30)
> Then perhaps we should ASAP change
> handle_counted_by_attribute so that it emits a sorry message if
> (c_dialect_cxx ()),
> either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116155
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Dimitar Dimitrov from comment #7)
> Size of only_fam_2 is 1.
sizeof (int) and alignof (int) still is 4?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116155
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Dimitar Dimitrov from comment #5)
>
> What fails on pru is:
> if (sizeof (struct only_fam_2) != sizeof (int))
> __builtin_abort ();
>
> I think we need to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116155
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=116016
--- Comment #45 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #42)
>
> But for the kernel you'll need to have fallback code which will set the
> actual counter manually for compilers without support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #44 from qinzhao at gcc dot gnu.org ---
(In reply to uecker from comment #41)
> I also do not yet understand why this feature is needed. The count should be
> set anyway.
Yes. But setting the count in _every_ place where a str
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #40 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #39)
>
> But this all relies upon the 'counted_by' attribute existing. For this
> example:
>
> typeof(*__builtin_ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #38 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #37)
> I realized my error after sending this. So yeah it's not going to work. I'm
> okay with what's being discussed. I just wan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #35 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #33)
>
> We could then have a builtin to get the attribute's argument:
>
> __builtin_get_attr_arg (ptr, attr_name);
not sure wheth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #34 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #33)
>
> If we had a way of testing for an attribute, we could avoid the need to
> return ( void *)0 when the '__builtin_get' can&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #29 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #28)
> It would need to be a FE keyword where __builtin_get_counted_by would return
> some pointer, either e.g. (void *)0 if it doesn't have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #22 from qinzhao at gcc dot gnu.org ---
the following is the user documentation I came up based on all the discussion
so far, let me know any comment and suggestion. (refer to GCC's
__builtin_clear_padding doc on the prototype o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #20 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #19)
> > Does it have to be a FAM? What is the problem if this is used on, e.g. an
> > arbitrary pointer?
> >
>
> IMO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #17 from qinzhao at gcc dot gnu.org ---
(continue with the comment #16):
the compiler's responsibility is:
A. check whether p->fam has counted-by attribute or not;
B. get the corresponding counted-by field for p->fam and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #16 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #15)
> (In reply to qinzhao from comment #14)
> > If we go with the category B (as I mentioned in Comment #9), define the new
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #14 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #13)>
> Does it have to be a FAM? What is the problem if this is used on, e.g. an
> arbitrary pointer?
If we go with the categor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Bill Wendling from comment #10)
> The Clang implementation will probably have a prototype of something like:
>
> void __builtin_set_counted_by(void *, size_t)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> It doesn't matter how it is documented, what matters is how it is
> implemented.
> E.g. can you do (__builtin_call_with_static_c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #6)
> That is a bad example, __builtin_call_with_static_chain is not a builtin
> function, but a keyword.
A little confused here, this funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> That is not a prototype. Prototype is what is the C or C++ function type of
> the builtin. Neither ptr->FAM nor const_exp_with_int_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
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=115527
--- Comment #9 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to qinzhao from comment #6)
> > --- a/gcc/gimple-fold.cc
> > +++ b/gcc/gimple-fold.cc
> > @@ -4815,6 +4815,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527
--- Comment #6 from qinzhao at gcc dot gnu.org ---
This is a bug in gimple-fold.cc, when folding __builtin_clear_padding.
The problematic code is in the routine "clear_padding_type" when the TYPE is
ARRAY_TYPE.
/* For su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527
--- Comment #5 from qinzhao at gcc dot gnu.org ---
the following code in gimple-fold.cc has issue:
4440 tree dst = build2_loc (buf->loc, MEM_REF, atype, buf->base,
4441 build_int_cst (buf->a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527
--- Comment #4 from qinzhao at gcc dot gnu.org ---
when checking the expanded IR for __builtin_clear_padding in the below:
the builtin
__builtin_clear_padding (&o, 0B);
was expanded as the following sequence
D.4430 = &o + 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527
--- Comment #3 from qinzhao at gcc dot gnu.org ---
I believe that this is a bug in __builtin_clear_padding.
when I change the testing case to:
struct inner {
double a;
char b;
long l;
};
struct outer {
struct inner in_array[3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111775
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111775
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115527
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=111775
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Cristian Rodríguez from comment #1)
> Any hope of getting this fixed for 15? it is quite annoying when trying to
> update older codebases to use c99 FAM.
a slightly modified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111567
Bug 111567 depends on bug 108896, which changed state.
Bug 108896 Summary: provide "element_count" attribute to give more context to
__builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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 th
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 p
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 realloca
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 optim
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 fo
1 - 100 of 380 matches
Mail list logo
