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
'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
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
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
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
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
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.
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
'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
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
> 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
> 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 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 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
.
* 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:
>>>
>&
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
>
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:
>
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.
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
'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
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
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
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
> 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
> 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 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
> 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 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 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:
>>>
>>>
&
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,
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
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,
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
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
> 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
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
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
-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
> 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
> On Nov 3, 2023, at 12:30 PM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 04:20:57PM +0000, Qing Zhao wrote:
>> So, based on the discussion so far, We will define the .ACCESS_WITH_SIZE as
>> following:
>>
>> .ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE
nt or suggestion.
Qing
On Nov 3, 2023, at 2:32 AM, Martin Uecker wrote:
>
>
> Am Freitag, dem 03.11.2023 um 07:22 +0100 schrieb Jakub Jelinek:
>> On Fri, Nov 03, 2023 at 07:07:36AM +0100, Martin Uecker wrote:
>>> Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill
> On Nov 3, 2023, at 10:46 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 02:32:04PM +0000, Qing Zhao wrote:
>>> Why? It doesn't really matter. The options are
>>> A. p is at [2] associated with and int type (or size of int
>>> or whatev
> On Nov 3, 2023, at 2:22 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 07:07:36AM +0100, Martin Uecker wrote:
>> Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill Wendling:
>>> On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote:
>>>>
>&g
> On Nov 2, 2023, at 8:09 AM, Jakub Jelinek wrote:
>
> On Thu, Nov 02, 2023 at 12:52:50PM +0100, Richard Biener wrote:
>>> What I meant is to emit
>>> tmp_4 = .ACCESS_WITH_SIZE ([0], , (typeof ()) 0);
>>> p_5 = _4[2];
>>> i.e. don't associate the pointer with a value of the size, but with
>>>
> On Nov 2, 2023, at 7:52 AM, Richard Biener wrote:
>
> On Thu, Nov 2, 2023 at 11:40 AM Jakub Jelinek wrote:
>>
>> On Thu, Nov 02, 2023 at 11:18:09AM +0100, Richard Biener wrote:
Or, if we want to pay further price, .ACCESS_WITH_SIZE could take as one of
the arguments not the size
Thanks a lot for raising these issues.
If I understand correctly, the major question we need to answer is:
For the following example: (Jakub mentioned this in an early message)
1 struct S { int a; char b __attribute__((counted_by (a))) []; };
2 struct S s;
3 s.a = 5;
4 char *p = [2];
> On Nov 2, 2023, at 9:54 AM, Richard Biener wrote:
>
> On Thu, Nov 2, 2023 at 2:50 PM Qing Zhao wrote:
>>
>>
>>
>>> On Nov 2, 2023, at 3:57 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wro
> On Nov 2, 2023, at 3:57 AM, Richard Biener wrote:
>
> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wrote:
>>
>>
>>
>>> On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
>>>
>>> On Tue, 31 Oct 2023, Qing Zhao wrote:
>>>
Joseph and Martin,
For the task to replace every reference to a FAM field with an call to
.ACCESS_WITH_SIZE,
Where in the C FE I should look at?
Thanks a lot for the help.
Qing
> On Nov 1, 2023, at 11:00 AM, Martin Uecker wrote:
>
> Am Mittwoch, dem 01.11.2023 um 14:47 + schrieb Qing Zhao:
>>
>>> On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
>>>
>>> On Tue, 31 Oct 2023, Qing Zhao wrote:
>>>
>>&g
> On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
>
> On Tue, 31 Oct 2023, Qing Zhao wrote:
>
>> 2.3 A new semantic requirement in the user documentation of "counted_by"
>>
>> For the following structure including a FAM with a counted_by attribute:
> On Oct 31, 2023, at 1:35 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-31 12:26, Qing Zhao wrote:
>> Hi,
>> I wrote a summary based on our extensive discussion, hopefully this can be
>> served as an informal proposal.
>> Please take a look at it and let
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
Okay, thanks for the explanation.
We will keep this in mind.
Qing
> On Oct 27, 2023, at 1:19 PM, Kees Cook wrote:
>
> On Fri, Oct 27, 2023 at 03:10:22PM +0000, Qing Zhao wrote:
>> Since the dynamic array support is quite important to the kernel (is this
>> true, Kees
About where we should insert the new __builtin_with_access_and_size:
> On Oct 26, 2023, at 2:54 PM, Qing Zhao wrote:
>
>
>
>> On Oct 26, 2023, at 10:05 AM, Richard Biener
>> wrote:
>>
>>
>>
>>> Am 26.10.2023 um 12:14 schrieb Martin Uec
> On Oct 27, 2023, at 10:53 AM, Martin Uecker wrote:
>
> Am Freitag, dem 27.10.2023 um 14:32 + schrieb Qing Zhao:
>>
>>> On Oct 27, 2023, at 3:21 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 19:57 + schrieb Qing Zhao:
> On Oct 27, 2023, at 3:21 AM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 19:57 + schrieb Qing Zhao:
>> I guess that what Kees wanted, ""fill the array without knowing the actual
>> final size" code pattern”, as following:
>&g
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
>>>>>>>
>>>>>>> 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
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
> 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
> 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 25, 2023, at 6:06 PM, Kees Cook wrote:
>
> On Wed, Oct 25, 2023 at 01:27:29PM +0000, Qing Zhao wrote:
>> A. Add an additional argument, the size parameter, to __bdos,
>> A.1, during FE;
>> A.2, during gimplification phase;
>
> I just wanted
> On Oct 25, 2023, at 11:38 AM, Richard Biener
> wrote:
>
>
>
>> Am 25.10.2023 um 16:50 schrieb Siddhesh Poyarekar :
>>
>> On 2023-10-25 09:27, Qing Zhao wrote:
>>>>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar
>>>
> On Oct 25, 2023, at 10:50 AM, Siddhesh Poyarekar wrote:
>
> On 2023-10-25 09:27, Qing Zhao wrote:
>>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-10-24 18:51, Qing Zhao wrote:
>>>> Thanks for the proposal!
>
t;>>> 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 20:30 + schrieb Qing Zhao:
>>
iener:
>>>>
>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>
>>>>> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>>>>>> Hi, Sid,
>>>>>>
>>>>>> Real
> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-24 18:51, Qing Zhao wrote:
>> Thanks for the proposal!
>> So what you suggested is:
>> For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
>> then the call to th
> 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
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 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:
>
> 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 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:
> 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 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 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 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 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 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 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)));
g 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 16:22, Qing Zhao via Gcc-patches wrote:
>
>> Comparing
> 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
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
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
> 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 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
>>> + 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 =
-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
?
>
> * * *
>
> 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
101 - 200 of 1164 matches
Mail list logo
