: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #1)
> -fno-strict-overflow maps directly to -fwrapv .
>
> If you want to use -fsanitize=signed-integer-overflow, you can just remove
> both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed. So we end with '&__closure->__this' which indeed isn't an lvalue.
>
> The issue here is that we are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #8 from qinzhao at gcc dot gnu.org ---
the ICE is triggered by the following IR:
MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);
which is transformed from the original IR:
(*fb.1_9) = .DEFERRED_INIT (16, 2, 1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #9 from qinzhao at gcc dot gnu.org ---
the direct cause of the ICE is because:
MEM[(int[0:D.1993] *)&fb.3] = .DEFERRED_INIT (16, 2, 1);
in the above, the fb.3 is in REG instead MEM:
8451 gcc_assert (MEM_P (re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #10 from qinzhao at gcc dot gnu.org ---
commented the following transformation in tree-ssa-ccp.c:
2733 #if 0
2734 /* The heuristic of fold_builtin_alloca_with_align differs before
and
2735after inlining, so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #12 from qinzhao at gcc dot gnu.org ---
with the following change, I can resolve the ICE:
[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index 70ce6a4d5b8d..b07026165075 100644
--- a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #15 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> Because the variable doesn't need to be addressable.
>
> OK, so the issue is likely that we're probing the lhs with EXPAND_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #17 from qinzhao at gcc dot gnu.org ---
> > OK, so the issue is likely that we're probing the lhs with EXPAND_WRITE but
> > when we expand the memset we end up with using expand_expr_addr_expr_1
> > with EX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #18 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> We could try sth like the following which should cover this testcase and
> also hopefully doesn't break anything else.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102587
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 #25 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #22)
> Hmm, my proposed patch seems to work. I've adjusted it to not regress
> previously correctly handled cases and will test it fully.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #26 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #25)
> (In reply to Richard Biener from comment #22)
> > Hmm, my proposed patch seems to work. I've adjusted it to not regress
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #28 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #21)
> Reduced testcase:
>
> int
> qy (void)
> {
> int tw = 4;
> int fb[tw];
> return fb[2];
> }
For this reduced tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #7 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> __builtin_clear_padding when folded emits a series of memory stores rather
> than BIT_INSERT_EXPR etc., so that wouldn't work.
&g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> Sure, you can, but just note that it is conservative and fast, it will
> return true even for types that don't have any padding.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> and if you have a variable that isn't addressable, you need to figure out
> what to do. I think it might be easiest not to clear anythi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #14 from qinzhao at gcc dot gnu.org ---
All the 3 testing cases can be resolved by adding the following patch (check
whether the type has padding before adding call to __builtin_clear_padding):
I believe that this is a safe partial
Version: 12.0
Status: UNCONFIRMED
Severity: normal
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=102781
--- Comment #1 from qinzhao at gcc dot gnu.org ---
This is a placeholder to an known issue with -ftrivial-auto-var-init:
If a long double/_Complex long double auto variable has explicit initializer,
and when this variable is spilled into stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #15 from qinzhao at gcc dot gnu.org ---
A summary of this bug based on discussion and more study:
multiple issues in the current implemenation:
A. should check is_gimple_reg before adding the call to
__builtin_clear_padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #16 from qinzhao at gcc dot gnu.org ---
Created attachment 51662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51662&action=edit
proposed patch to gcc12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102941
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=102281
--- Comment #18 from qinzhao at gcc dot gnu.org ---
fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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=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=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=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=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
--- 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 ot
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=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
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
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=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=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=101891
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
--- Comment #3 from qinzhao at gcc dot gnu.org ---
fixed in gcc13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105539
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=105539
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to qinzhao from comment #5)
> I am a little confused:
>
> with gcc -Wuninitialized -O1 (without -ftrivial-auto-var-init=zero), there
> are two issues:
>
> 1. the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
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=101836
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #7)
> I couldn't work on -fstrict-flex-arrays then, sorry. I do have it in my
> plan for gcc 13, but I'll admit it's not on th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #12 from qinzhao at gcc dot gnu.org ---
In the current tree-object-size.cc, "addr_object_size", it's clearly state the
following:
607 /* For &X->fld, compute object size only if f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #14 from qinzhao at gcc dot gnu.org ---
(In reply to Kees Cook from comment #13)
> Maybe the enum needs to also be expanded so that [0] can be distinguished
> from []?
I believe that the IR for real flexible array [] is dif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #15 from qinzhao at gcc dot gnu.org ---
the following patch will fix the issue with this testing case:
[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index 5ca87ae3504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #16 from qinzhao at gcc dot gnu.org ---
additional work are needed in order to make this task complete:
1. add one more new gcc option:
-fstrict-flex-arrays
when it's on, only treat the following cases as flexing array:
tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #25 from qinzhao at gcc dot gnu.org ---
So, based on all the discussion so far, how about the following:
** add the following gcc option:
-fstrict-flex-arrays=[0|1|2|3]
when -fstrict-flex-arrays=0:
treat all trailing arrays as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #29 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #28)
> (In reply to Qing Zhao from comment #27)
> > > Wouldn't this be -fno-strict-flex-arrays, i.e. the current behaviour?
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
--- Comment #32 from qinzhao at gcc dot gnu.org ---
(In reply to James Y Knight from comment #31)
> It doesn't make sense to have a mode in which `int array[0]` is accepted but
> is not a flex array.
>
> Either that should
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
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 #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 l
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&action=edit
tar b
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: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: qinzhao at gcc dot gnu.org
Target Milestone: ---
gcc12 failed with the following small testing case:
namespace std {
inline namespace __cxx11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #4 from qinzhao at gcc dot gnu.org ---
I applied the attached patch and tested CPU2017 with
-ftrivial-auto-var-init=pattern, now all the corresponding C++ failures get
resolved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101586
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> Reduced testcase:
> struct A { char a; };
> struct B : virtual A {};
> struct C : B {};
>
> void
> foo ()
> {
> C c;
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=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=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
--- 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=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=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=111407
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status
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.
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
: 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
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
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 #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=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
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=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
--- 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 #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 #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 #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=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 #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 #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 #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 #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 #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 #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=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=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
--- 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=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 #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=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=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=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 #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 #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:
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=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
201 - 300 of 349 matches
Mail list logo
