> On Nov 2, 2023, at 8:13 PM, Bill Wendling wrote:
>
> On Thu, Nov 2, 2023 at 1:00 AM Richard Biener
> wrote:
>>
>> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wrote:
>>>
>>>
>>>
>>>> On Oct 31, 2023, at 6:14 PM, Josep
-obtaining purpose in the source
code.
I will update the proposal one more time.
thanks.
Qing
> On Nov 2, 2023, at 8:28 PM, Bill Wendling wrote:
>
> On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote:
>>
>> Thanks a lot for raising these issues.
>>
>> If I understand
te and its
consumers
Qing Zhao
11/06/2023
==
The whole discussion is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633783.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634844.html
1. The problem
There is a data dependency betwee
for all the help.
Qing.
Represent the missing dependence for the "counted_by" attribute and its
consumers
Qing Zhao
10/30/2023
==
The whole discussion is at:
https://gcc.gnu.org/pip
> On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-23 14:06, Martin Uecker wrote:
>> We should aim for a good integration with the BDOS pass, so
>> that it can propagate the information further, e.g. the
>> following should work:
>> struct { int L; char buf[]
> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
>> Am Montag, dem 23.10.2023 um 16:37 +0000 schrieb Qing Zhao:
>>>
>>>> On Oct 23, 2023, at 11:57 AM, Richard Biener
>>>>
> On Oct 20, 2023, at 3:54 PM, Martin Uecker wrote:
>
> Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao:
>>
>>> On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
>>>
>>> On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote:
>>
> On Oct 23, 2023, at 3:37 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 19:00 + schrieb Qing Zhao:
>>
>>> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote:
>>>
>>> Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
>
Hi, Sid,
Really appreciate for your example and detailed explanation. Very helpful.
I think that this example is an excellent example to show (almost) all the
issues we need to consider.
I slightly modified this example to make it to be compilable and run-able, as
following:
(but I still
> On Oct 24, 2023, at 4:38 PM, Martin Uecker wrote:
>
> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>> Hi, Sid,
>>
>> Really appreciate for your example and detailed explanation. Very helpful.
>> I think that this example is an excel
> On Oct 24, 2023, at 5:03 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-24 16:30, Qing Zhao wrote:
>> Situation 2: With O0, the routine “get_size_from” was NOT inlined into
>> “foo”, therefore, the call to __bdos is Not in the same routine as the
>> instantiation
> On Oct 26, 2023, at 1:21 AM, Jakub Jelinek wrote:
>
> On Wed, Oct 25, 2023 at 07:03:43PM +0000, Qing Zhao wrote:
>> For the code generation impact:
>>
>> turning the original x.buf
>> to a builtin function call
>> __builtin_with_access_and_size(x
> On Oct 26, 2023, at 4:56 AM, Richard Biener
> wrote:
>
> On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote:
>>
>> On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote:
>>> For the code generation impact:
>>>
>>> turning
Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
>>>>>>>>
>>>>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>>>>>
>>>>>>>>> Am Dienstag, dem 24.10.2023 um
>>>>>>>
>>>>>>> Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar:
>>>>>>>>> On 2023-10-25 04:16, Martin Uecker wrote:
>>>>>>>>> Am Mittwoch, dem 25.10.2
I guess that what Kees wanted, ""fill the array without knowing the actual
final size" code pattern”, as following:
>> struct foo *f;
>> char *p;
>> int i;
>>
>> f = alloc(maximum_possible);
>> f->count = 0;
>> p = f->buf;
>>
>> for (i; data_is_available() &&
> On Oct 26, 2023, at 1:05 PM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>>
>>> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Bi
Hi,
I’d like to ping this patch set one more time.
Thanks
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> Provide a new counted_by attribute to flexible array member field.
>
> 'counted_by (COUNT)'
> The 'counted_by' attribute may be attached to
Hi,
I’d like to ping this patch set one more time.
Thanks
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> Use the counted_by atribute info in builtin object size to compute the
> subobject size for flexible array members.
>
> gcc/ChangeLog:
>
> PR
Hi,
I’d like to ping this patch set one more time.
Thanks
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> Use the counted_by attribute information in bound sanitizer.
>
> gcc/c-family/ChangeLog:
>
> PR C/108896
> * c-ubsan.cc (ubsan_instrument
Hi,
I’d like to ping this patch set one more time!
Thanks.
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> This is the 3rd version of the patch, per our discussion based on the
> review comments for the 1st and 2nd version, the major changes in this
> version are:
?
>
> * * *
>
> Cross ref: The patch adding the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously
> in this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08.23 1
> On Sep 17, 2023, at 12:36 PM, Hans-Peter Nilsson via Gcc-patches
> wrote:
>
>> From: Sam James
>> Date: Sun, 17 Sep 2023 05:00:37 +0100
>
>> Hans-Peter Nilsson via Gcc-patches writes:
>>
Date: Tue, 29 Aug 2023 15:42:27 -0400
From: Marek Polacek via Gcc-patches
>>>
> On Oct 18, 2023, at 11:18 AM, Siddhesh Poyarekar wrote:
>
> On 2023-10-18 10:51, Qing Zhao wrote:
>>>>> + member FIELD_DECL is a valid field of the containing structure's
>>>>> fieldlist,
>>>>> + FIELDLIST, Report error and remov
-25 11:24, Qing Zhao wrote:
>> Provide a new counted_by attribute to flexible array member field.
>
> The obligatory "I can't ack the patch but here's a review" disclaimer :)
>
>> 'counted_by (COUNT)'
>> The 'counted_by' attribute may be attached to th
>>> + member FIELD_DECL is a valid field of the containing structure's
>>> fieldlist,
>>> + FIELDLIST, Report error and remove this attribute when it's not. */
>>> +static void
>>> +verify_counted_by_attribute (tree fieldlist, tree field_decl)
>>> +{
>>> + tree attr_counted_by =
Marek,
Sorry for the late comment (I was just back from a long vacation immediate
after Cauldron).
One question:
Is the option “-fhandened” for production build or for development build?
If it’s for development build, then adding -ftrivial-auto-var-init=pattern is
reasonable since the
Hi, Sid,
Thanks a lot for the detailed comments.
See my responds embedded below.
Qing
> On Oct 5, 2023, at 4:01 PM, Siddhesh Poyarekar wrote:
>
>
>
> On 2023-08-25 11:24, Qing Zhao wrote:
>> Use the counted_by atribute info in builtin object size to compute
> On Oct 5, 2023, at 4:08 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-25 11:24, Qing Zhao wrote:
>> This is the 3rd version of the patch, per our discussion based on the
>> review comments for the 1st and 2nd version, the major changes in this
>> version are
> On Oct 6, 2023, at 4:01 PM, Martin Uecker wrote:
>
> Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar:
>> On 2023-10-06 01:11, Martin Uecker wrote:
>>> Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh
> On Oct 20, 2023, at 2:22 PM, Richard Biener
> wrote:
>
>
>
>> Am 20.10.2023 um 19:09 schrieb Qing Zhao :
>>
>> Sid,
>>
>> (Richard, can you please help me to make sure this? Thanks a lot)
>>
>> I studied a little bit more o
Sid,
(Richard, can you please help me to make sure this? Thanks a lot)
I studied a little bit more on the following question you raised during the
review process:
For the following small testing case:
1 struct annotated {
2 int foo;
3 char array[] __attribute__((counted_by (foo)));
> On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
>
> On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote:
>> Am Donnerstag, dem 19.10.2023 um 16:33 -0700 schrieb Kees Cook:
>>> On Wed, Oct 18, 2023 at 09:11:43PM +, Qing Zhao wrote:
>>>> As I r
> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-20 14:38, Qing Zhao wrote:
>> How about the following:
>> Add one more parameter to __builtin_dynamic_object_size(), i.e
>> __builtin_dynamic_object_size (_1,1,array_annotated->foo)?
>
> On Oct 23, 2023, at 3:57 AM, Richard Biener
> wrote:
>
> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
>>
>>
>>
>>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-10-20 14:38, Qing Zhao wrote:
&
> On Oct 23, 2023, at 8:34 AM, Richard Biener
> wrote:
>
> On Mon, Oct 23, 2023 at 1:27 PM Siddhesh Poyarekar
> wrote:
>>
>> On 2023-10-23 03:57, Richard Biener wrote:
>>> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
>>>>
>>
> On Oct 23, 2023, at 11:57 AM, Richard Biener
> wrote:
>
>
>
>> Am 23.10.2023 um 16:56 schrieb Qing Zhao :
>>
>>
>>
>>> On Oct 23, 2023, at 3:57 AM, Richard Biener
>>> wrote:
>>>
>>>> On Fri, Oct 20, 2023
> On Oct 23, 2023, at 2:06 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao:
>>
>>> On Oct 23, 2023, at 11:57 AM, Richard Biener
>>> wrote:
>>>
>>>
>>>
>>>> Am 23.10.2023 um 16:
te and its
consumers
Qing Zhao
11/09/2023
==
The whole discussion is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633783.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634844.html
https://gcc.gnu.org/pipermail/gcc-patches/202
Hi,
This is the 4th version of the patch.
It based on the following proposal:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635884.html
Represent the missing dependence for the "counted_by" attribute and its
consumers
**The summary of the proposal is:
* Add a new internal
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
Since the result type of the call to .ACCESS_WITH_SIZE is a pointer to
the element type. The original array_ref is converted to an indirect_ref,
which introduced two issues for the instrumenation of bound sanitizer:
A. The index for the original array_ref was mixed into the offset
expression for
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
Thanks.
Qing
> On Feb 9, 2024, at 10:54 AM, Qing Zhao wrote:
>
> Hi,
>
> This is the 5th version of the patch.
>
> compare with the 4th version, the major difference are:
>
> 1. Change the return type of the routine .ACCESS_WITH_SIZE
> FROM:
> Pointer to
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
*
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
the first
reference to the FAM field.
* the array has at least # of elements specified by the size field all
the time during the program.
I have bootstrapped and regression tested on both x86 and aarch64, no issue.
Linux kernel linux-6.8-rc4 has been built and exposed one bug with the new
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
Hi,
This is the 5th version of the patch.
compare with the 4th version, the major difference are:
1. Change the return type of the routine .ACCESS_WITH_SIZE
FROM:
Pointer to the type of the element of the flexible array;
TO:
Pointer to the type of the flexible array;
And
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
*
with this solution.
thanks.
Qing
> On Nov 30, 2023, at 11:07 AM, Qing Zhao wrote:
>
> Hi,
>
> 1. For the following source code (portion):
>
> struct annotated {
> size_t foo;
> char b;
> char array[] __attribute__((counted_by (foo)));
> };
>
> static vo
Hi,
I have some questions on using the utility routine “unshare_expr”:
From my understanding, there should be NO shared nodes in a GENERIC function.
Otherwise, gimplication might fail.
Therefore, when we insert new tree nodes manually into the GENERIC function, we
should
Make sure there is
> On Jan 15, 2024, at 4:31 AM, Richard Biener
> wrote:
>
>> All my questions for unshare_expr relate to a LTO bug that I currently
>> stuck with
>> when using .ACCESS_WITH_SIZE in bound sanitizer (only with -flto, without
>> -flto, no issue):
>>
>> [opc@qinzhao-aarch64-ol8 gcc]$ sh t
>>
> On Jan 15, 2024, at 10:06 AM, Jakub Jelinek wrote:
>
> On Mon, Jan 15, 2024 at 02:54:26PM +0000, Qing Zhao wrote:
>> So, before gimplification, when inserting tree node, we don’t need manually
>> add unshare_expr since the gimplification will automa
> On Jan 15, 2024, at 4:31 AM, Richard Biener
> wrote:
>
> On Fri, Jan 12, 2024 at 6:30 PM Qing Zhao wrote:
>>
>> Thanks a lot for the reply.
>>
>>> On Jan 12, 2024, at 11:28 AM, Richard Biener
>>> wrote:
>>>
>>>
&
> On Jan 15, 2024, at 3:13 AM, Eric Botcazou wrote:
>
>> Okay, so, the "unsharing everything” is done automatically by the compiler
>> before gimplification?
>
> See the blurb at gimplify.cc:835 and below about this.
Thanks a lot for the info. (I read this paragraph before sending the
> On Jan 17, 2024, at 1:43 AM, Richard Biener
> wrote:
>
> On Wed, Jan 17, 2024 at 7:42 AM Richard Biener
> wrote:
>>
>> On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao wrote:
>>>
>>>
>>>
>>>> On Jan 15, 2024, at
Thanks a lot for the reply.
> On Jan 12, 2024, at 11:28 AM, Richard Biener
> wrote:
>
>
>
>> Am 12.01.2024 um 16:55 schrieb Qing Zhao :
>>
>> Hi,
>>
>> I have some questions on using the utility routine “unshare_expr”:
>>
>&g
Hi,
1. For the following source code (portion):
struct annotated {
size_t foo;
char b;
char array[] __attribute__((counted_by (foo)));
};
static void noinline bar ()
{
struct annotated *p2 = alloc_buf (10);
p2->array[8] = 0;
return;
}
2. I modified C FE to generate the following
.
* the array has at least # of elements specified by the size field all the
time during the program.
* the value of counted-by should not be negative.
Let me know your comment and suggestions.
Thanks
Qing
> On Jan 25, 2024, at 3:11 PM, Qing Zhao wrote:
>
> Thanks a lot for the
Thank you!
Joseph and Richard, could you also comment on this?
> On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote:
>
> Am Freitag, dem 26.01.2024 um 14:33 + schrieb Qing Zhao:
>>
>>> On Jan 26, 2024, at 3:04 AM, Martin Uecker wrote:
>>>
>&
> On Jan 29, 2024, at 10:50 AM, Martin Uecker wrote:
>
> Am Montag, dem 29.01.2024 um 15:09 + schrieb Qing Zhao:
>> Thank you!
>>
>> Joseph and Richard, could you also comment on this?
>>
>>> On Jan 28, 2024, at 5:09 AM, Martin Uecker wrote:
&g
> On Jan 29, 2024, at 3:35 PM, Joseph Myers wrote:
>
> On Mon, 29 Jan 2024, Qing Zhao wrote:
>
>> Thank you!
>>
>> Joseph and Richard, could you also comment on this?
>
> I think Martin's suggestions are reasonable.
Okay, I will update the patches ba
> On Jan 29, 2024, at 12:25 PM, Kees Cook wrote:
>
> On Mon, Jan 29, 2024 at 04:00:20PM +0000, Qing Zhao wrote:
>> An update on the kernel building with my version 4 patch.
>>
>> Kees reported two FE issues with the current version 4 patch:
>>
>>
> On Jan 29, 2024, at 3:19 PM, Kees Cook wrote:
>
> On Mon, Jan 29, 2024 at 07:32:06PM +0000, Qing Zhao wrote:
>>
>>
>>> On Jan 29, 2024, at 12:25 PM, Kees Cook wrote:
>>>
>>> On Mon, Jan 29, 2024 at 04:00:20PM +, Qing Zhao wrote:
>>
> On Jan 19, 2024, at 4:30 AM, Richard Biener
> wrote:
>
> On Thu, Jan 18, 2024 at 3:46 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jan 17, 2024, at 1:43 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jan 17, 2024 at 7:42 AM Ric
> On Jan 30, 2024, at 12:41 AM, Kees Cook wrote:
>
> On Mon, Jan 29, 2024 at 10:45:23PM +0000, Qing Zhao wrote:
>> There are two things here.
>>
>> 1. The value of the “counted-by” is 0; (which is easy to be understood)
>> 2. The result of the _builtin_obje
by is zero;
Array bound sanitizer will report out-of-bound when the counted-by is
zero for any array access.
Let me know if I missed anything.
Thanks a lot for all the comments
Qing
> On Jan 23, 2024, at 7:29 PM, Qing Zhao wrote:
>
> Hi,
>
> This is the
ially in C FE
for the new internal function .ACCESS_WITH_SIZE.
(I have specially handle the operator “offsetof” in C FE already).
Will fix this issue.
Thanks.
Qing
> On Jan 24, 2024, at 7:51 PM, Kees Cook wrote:
>
> On Wed, Jan 24, 2024 at 12:29:51AM +, Qing Zhao wrote:
>
Thanks.
Qing
>
> Martin
>
>
> Am Donnerstag, dem 25.01.2024 um 20:11 + schrieb Qing Zhao:
>> Thanks a lot for the testing.
>>
>> Yes, I can repeat the issue with the following small example:
>>
>> #include
>> #include
>> #include
>
> On Jan 22, 2024, at 2:40 AM, Richard Biener
> wrote:
>
> On Fri, Jan 19, 2024 at 5:26 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jan 19, 2024, at 4:30 AM, Richard Biener
>>> wrote:
>>>
>>> On Thu, Jan 18, 2024 at 3:46 PM Qin
the LTO issue anymore with the latest trunk + my counted-by support
patches.
I.e., without the LTO workaround, everything works just fine with the latest
gcc.
I suspected that some change in the latest GCC “fixed” (or hide) the issue.
Qing
> On Jan 22, 2024, at 9:52 AM, Qing Zhao wr
this feature.
thanks.
Qing
> On Nov 6, 2023, at 7:12 PM, Qing Zhao wrote:
>
> Hi,
>
> Attached is the 2nd version of the proposal based on all the discussion so
> far.
>
> Let me know if you have more comment and suggestion.
>
> Thanks a l
> On Nov 9, 2023, at 11:50 AM, Jose Marchesi wrote:
>
>>
>> On Thu, Nov 09, 2023 at 03:49:49PM +, Qing Zhao wrote:
>>> Is it reasonable to add one option to disable the “counted_by” attribute?
>>> (then no insertion of the new .ACCESS_WITH_SIZE i
Ping on this patch set.
Thanks a lot!
Qing
> On Feb 16, 2024, at 14:47, Qing Zhao wrote:
>
> Hi,
>
> This is the 6th version of the patch.
>
> compare with the 5th version, the only difference is:
>
> 1. Add the 6th argument to .ACCESS_WITH_SIZE
> to carry
On Mar 13, 2024, at 15:19, Qing Zhao wrote:
On Mar 11, 2024, at 13:15, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc
On Mar 13, 2024, at 15:17, Qing Zhao wrote:
On Mar 11, 2024, at 13:11, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog
> On Mar 18, 2024, at 12:30, Siddhesh Poyarekar wrote:
>
> On 2024-03-18 12:28, Qing Zhao wrote:
>>>> This should probably bail out if object_size_type & OST_DYNAMIC == 0.
>>> Okay. Will add this.
>> When add this into access_with
Sid,
Thanks a lot for your time to review the code.
See my reply below:
On Mar 11, 2024, at 10:57, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
return true;
else
return targetm.attribute_takes_identifier_p (attr_id);
@@ -2806,6 +2811,53
On Mar 19, 2024, at 09:46, Jakub Jelinek wrote:
On Tue, Mar 19, 2024 at 01:14:51PM +, Qing Zhao wrote:
Currently, the OST_DYNAMIC information is not passed to
early_object_sizes phase. Pass this information to it, and adjust the code
and testing case accordingly.
Can you explain why do
Currently, the OST_DYNAMIC information is not passed to
early_object_sizes phase. Pass this information to it, and adjust the code
and testing case accordingly.
bootstrapped and regress tested on both x86 and aarch64. no issue.
Okay for trunk?
thanks.
Qing
gcc/ChangeLog:
*
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
*
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member.
GCC may use
Hi,
This is the 7th version of the patch.
compare with the 6th version, the difference are:
updates per Siddhesh's comments:
1. update the error messages in "handle_counted_by_attribute"
then update the testing case accordingly;
2. update the error messages in "verify_counted_by_attribute"
On Mar 11, 2024, at 13:11, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new
> On Mar 11, 2024, at 13:09, Siddhesh Poyarekar wrote:
>
>
>
> On 2024-02-16 14:47, Qing Zhao wrote:
>> Including the following changes:
>> * The definition of the new internal function .ACCESS_WITH_SIZE
>> in internal-fn.def.
>> * C FE converts ever
On Mar 11, 2024, at 13:15, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array-counted-by-bounds-2.c: New test.
*
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
201 - 300 of 1165 matches
Mail list logo
