https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070
--- Comment #4 from qinzhao at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #2)
> Or with -fstrict-flex-arrays .
Ah, you are right, I forgot about this..
adding -fstrict-flex-arrays fixed this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121070
Bug ID: 121070
Summary: bounds sanitizer should instrument arrays inside a
structure
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #13 from qinzhao at gcc dot gnu.org ---
fixed in gcc16.
should be backported to GCC15 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
I just sent out the patches to gcc-patches alias to fix this bug and also
reduce the # of arguments from 6 to 4.
I splited the changes into 2 separ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #10 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #9)
> The problem if it is the scalar type rather than pointer to it is that it
> could be e.g. too narrow to fit all the ACCESS_MODE values there. Think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #7 from qinzhao at gcc dot gnu.org ---
I need to modify the testing case as following to enable
__builtin_dynamic_object_size working as expected:
/* The parameter m must be const qualified to avoid the m is
marked as TREE_SIDE_E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> Why do you need CLASS_OF_SIZE argument? If count is in bytes, simply pass 1
> to the TYPE_SIZE_UNIT argument.
> ACCESS_MODE can be in the same argum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #4 from qinzhao at gcc dot gnu.org ---
The size of the element of the FAM actually _cannot_ reliably depends on the
original TYPE of the FAM that we passed as the 6th parameter to the
.ACCESS_WITH_SIZE:
TYPE_SIZE_UNIT (TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> > we can cleanly see that _26 is an uninitialized variable, whose
> > initialization has been eliminated by the previous optimization already due
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
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=121000
--- Comment #1 from qinzhao at gcc dot gnu.org ---
with gcc -O1 -fdump-tree-all t.c, in a-t.c.112t.objsz1, we see the object size
is generated as _22:
sizetype _26(D);
_12 = &p_18->n;
_23 = MEM [(void *)_12];
_24 = MAX_EXPR <_23, 0>;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121000
Bug ID: 121000
Summary: __builtin_dynamic_object_size should work for FAM with
VLA element when annotated with counted_by
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #24 from qinzhao at gcc dot gnu.org ---
I have reverted the patches that triggered the issue.
will fix this issue in the next commit with the new patch set.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #23 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #21)
> (In reply to Richard Biener from comment #20)
> > so for
> >
> > _1 = _2;
> >
> > we merge from _2. For
> >
> > _1 = *_2;
> >
> > we _a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #16 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #12)
> This is interesting here's the IR dump right after objsz:
>
> The key bit is:
>
> map2_4 = __builtin_malloc (8);
> pin_pointer (&buf);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #14 from qinzhao at gcc dot gnu.org ---
(In reply to Siddhesh Poyarekar from comment #13)
> Here's a super-minimal test case:
>
thanks for the smaller testing case, it has the same behavior as the one Sergei
provided in comment #7: O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #10 from qinzhao at gcc dot gnu.org ---
(In reply to Sergei Trofimovich from comment #7)
>
> Crashing:
>
> $ gcc/xgcc -Bgcc -D_FORTIFY_SOURCE=3 -O1 apprentice.c -o bug && ./bug
> In file included from /usr/include/string.h:548,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Sergei Trofimovich from comment #3)
> (In reply to qinzhao from comment #2)
> > could you please reduce the testing case to help me debug?
>
> Will do. Might take some time as I'm n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Sam James from comment #4)
> Ah, nice. I had this during bootstrap but wasn't able to reduce yet.
you mean during bootstrap gcc itself? (I didn't see such issue when bootstrap
gcc b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120929
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=77650
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to uecker from comment #10)
> Should this warning be added to -Wall ?
I think that's a good idea to add it to -Wall.
but I am not sure whether it's too early to do it? my understanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120353
--- Comment #2 from qinzhao at gcc dot gnu.org ---
the following patch fixes the issue:
[opc@qinzhao-aarch64-ol8 c]$ git diff
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index ad66d7d258b..4733287eaf8 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120354
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=120354
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Ella Ma from comment #2)
> Sorry, I made a mistake when making the example.
> This problem happens when the flex-array member is not the last, **and the
> members below it are in a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120353
--- Comment #1 from qinzhao at gcc dot gnu.org ---
in the routine "finish_struct" of c-decl.cc, we have:
9660 if (warn_flex_array_member_not_at_end
9661 && !is_last_field
9662 && RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to uecker from comment #2)
> I guess you need to use c_fully_fold
Yes. thanks for the hints.
in c_fully_fold, it assumes:
/* Operands of variable-length expressions (function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
--- Comment #1 from qinzhao at gcc dot gnu.org ---
the reason for the ICE is:
in C FE, there is a C_MAYBE_CONST_EXPR that is generated for converting the
parameter "x" to integer type before comparing with integer constant 0 as:
arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
> If the compiler compiles it and it misbehaves at runtime, that is valid
> behavior for undefined behavior. ICE (as in the other PR) is something we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> This is invalid testcase.
> E.g. replace return __builtin_dynamic_object_size (p, 1); with return 0;
> and try both gcc -fsanitize=undefined -g -O0 o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
Bug ID: 119717
Summary: ICE in gimplify_expr, at gimplify.cc:20339 due to
counted_by attribute
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |qinzhao at gcc dot
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
Bug ID: 119716
Summary: segmentation fault when Passing NULL pointer to _bdos
with counted_by attribute
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Assignee|qinzhao at gcc dot gnu.org |unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117375
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
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 Init(1) in
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 qi
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 (_2);
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 ca
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 ca
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=]
16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UN
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: ‘__builtin___memset_ch
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 warning.
Yes, in this specific
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-thread-ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116735
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|AS
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.
> > >
> > > diff --git a/g
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 "counted_by" a
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 token sequence (wit
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585
Bug ID: 116585
Summary: SSA corruption with -O3,-fvect-cost-model=very-cheap
cures the failure
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
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 *)(&(array_annotated-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116316
Bug ID: 116316
Summary: incorrect code with -O2
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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:
After discuss
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 sense e
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
submit it
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
> #define BIGGEST_ALIGNMENT 8
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 as the first t
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 separate it into a
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 for counted_by
>
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 structure
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_get_counted_by(P->FAM)) idx;
>
> f
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 want to make it clear to the
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 whether it's worth the e
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't find the attribute:
>
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 a count, or a
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 of the
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 once we have support for 'counted
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 set it the va
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
> > builtin as a regul
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 category B (as I mentione
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)
>
> The 'void *' c
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
g
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_chain) (fn, ptr)?
> Or
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 function is clearly
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 are valid C
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
1 - 100 of 343 matches
Mail list logo
