> On Jul 18, 2023, at 12:03 PM, Martin Uecker wrote:
>
> Am Dienstag, dem 18.07.2023 um 15:37 + schrieb Qing Zhao:
>>
>>
>>> On Jul 17, 2023, at 7:40 PM, Kees Cook
>>> wrote:
>>>
>>> On Mon, Jul 17, 2023 at 09:17:48PM +,
> On Jul 18, 2023, at 11:37 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Jul 17, 2023, at 7:40 PM, Kees Cook wrote:
>>
>> On Mon, Jul 17, 2023 at 09:17:48PM +, Qing Zhao wrote:
>>>
>>>> On Jul 13, 2023, at 4:31 PM, Kees Cook
More thoughts on the following example Kees provided:
> On Jul 17, 2023, at 7:40 PM, Kees Cook wrote:
>>
>> The counted_by attribute is used to annotate a Flexible array member on how
>> many elements it will have.
>> However, if this information can not accurately reflect the real number of
>>
>> The point is: allocation size should synced with the value of “counted_by”.
>> LLVM’s RFC also have the similar requirement:
>> https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854#maintaining-correctness-of-bounds-annotations-18
>
> Right, I'm saying it woul
Hi,
In the current GCC13 release note, the URL to the option -fstrict-flex-array
is wrong (pointing to -Wstrict-flex-array).
This is the change to correct the URL and also add the URL in another place
where -fstrict-flex-array is mentioned.
I have checked the resulting HTML file, works well.
Oka
> On Jul 21, 2023, at 7:21 AM, Martin Uecker via Gcc-patches
> wrote:
>
>
>
> This patch adds a warning for allocations with insufficient size
> based on the "alloc_size" attribute and the type of the pointer
> the result is assigned to. While it is theoretically legal to
> assign to the wr
Hi, Sid and Jakub,
I have a question in the following source portion of the routine
“addr_object_size” of gcc/tree-object-size.cc:
743 bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
744 if (bytes != error_mark_node)
745 {
746 bytes = size_for_offset
Hi, Sid,
Thanks a lot.
> On Jul 31, 2023, at 1:07 PM, Siddhesh Poyarekar wrote:
>
> On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
>> On 2023-07-31 12:47, Qing Zhao wrote:
>>> Hi, Sid and Jakub,
>>>
>>> I have a question in the following source por
> On Jul 31, 2023, at 2:23 PM, Siddhesh Poyarekar wrote:
>
> On 2023-07-31 14:13, Qing Zhao wrote:
>> Okay. I see.
>> Then if the size info from the TYPE is smaller than the size info from the
>> malloc,
>> then based on the current code, we use the small
ltin_dynamic_object_size(p, 1), -1);
expect(__builtin_dynamic_object_size(p, 0), -1);
expect(__builtin_dynamic_object_size(p, 3), 0);
expect(__builtin_dynamic_object_size(p, 2), 0);
return 0;
}
> On Jul 19, 2023, at 2:52 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
> On Jul 31, 2023, at 1:07 PM, Siddhesh Poyarekar wrote:
>
> On 2023-07-31 13:03, Siddhesh Poyarekar wrote:
>> On 2023-07-31 12:47, Qing Zhao wrote:
>>> Hi, Sid and Jakub,
>>>
>>> I have a question in the following source portion of the routine
_size(q, 0) == -1
ok: __builtin_dynamic_object_size(q, 3) == 0
ok: __builtin_dynamic_object_size(q, 2) == 0
[opc@qinzhao-ol8u3-x86 108896]$
> On Aug 1, 2023, at 6:57 PM, Kees Cook wrote:
>
> On Tue, Aug 01, 2023 at 09:35:30PM +, Qing Zhao wrote:
>>
>>
>>>
> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote:
>
> On 6/28/22 13:01, Qing Zhao wrote:
>>> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote:
>>>
>>> On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
>>>>
>>>&
> On Jun 30, 2022, at 10:24 AM, Richard Biener
> wrote:
>
>
>
>> Am 30.06.2022 um 16:08 schrieb Qing Zhao via Gcc-patches
>> :
>>
>>
>>
>>> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote:
>>>
>>> On 6/28/22
> On Jun 30, 2022, at 1:03 PM, Jakub Jelinek wrote:
>
> On Thu, Jun 30, 2022 at 03:31:00PM +0000, Qing Zhao wrote:
>>> No, that’s not true. A FIELD_DELC is only shared for cv variants of a
>>> structure.
>>
>> Sorry for my dump questions:
>>
> On Jul 1, 2022, at 2:49 AM, Richard Biener wrote:
>
> On Thu, Jun 30, 2022 at 9:30 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jun 30, 2022, at 1:03 PM, Jakub Jelinek wrote:
>>>
>>> On Thu, Jun 30, 2022 at 03:31:00PM +, Qing Zhao w
> On Jul 1, 2022, at 8:58 AM, Richard Biener wrote:
>
> On Fri, Jul 1, 2022 at 2:55 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jul 1, 2022, at 2:49 AM, Richard Biener
>>> wrote:
>>>
>>> On Thu, Jun 30, 2022 at 9:30 PM Qing Zhao wr
> On Jul 1, 2022, at 8:59 AM, Jakub Jelinek wrote:
>
> On Fri, Jul 01, 2022 at 12:55:08PM +0000, Qing Zhao wrote:
>> If so, comparing to the current implemenation to have all the checking in
>> middle-end, what’s the
>> major benefit of moving part of the checki
(Sorry for the late reply, just came back from a short vacation.)
> On Jul 4, 2022, at 2:49 AM, Richard Biener wrote:
>
> On Fri, Jul 1, 2022 at 5:32 PM Martin Sebor wrote:
>>
>> On 7/1/22 08:01, Qing Zhao wrote:
>>>
>>>
>>>> On Jul 1, 20
> On Jul 7, 2022, at 4:02 AM, Richard Biener wrote:
>
> On Wed, Jul 6, 2022 at 4:20 PM Qing Zhao wrote:
>>
>> (Sorry for the late reply, just came back from a short vacation.)
>>
>>> On Jul 4, 2022, at 2:49 AM, Richard Biener
>>> wrote:
>>
Hi,
Based on the previous discussion on the Version 1 of the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597350.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598010.html
We decided:
*User interface:
. command line option in C/C++:
-fstrict-flex-array[=N]
>From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Jul 2022 17:04:12 +
Subject: [PATCH 1/2] Add a new option -fstrict-flex-array[=n] and new
attribute strict_flex_array
Add the following new option -fstrict-flex-array[=n] and a correspond
>From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Jul 2022 18:12:26 +
Subject: [PATCH 2/2] Use new flag DECL_NOT_FLEXARRAY in __builtin_object_size
[PR101836]
Use new flag DECL_NOT_FLEXARRAY to determine whether the trailing array
o
> On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
>
> On Tue, 19 Jul 2022, Qing Zhao wrote:
>
>> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
>> From: Qing Zhao
>> Date: Mon, 18 Jul 2022 18:12:26 +
>> Subject: [PATCH 2/2
Hi, Richard,
Thanks a lot for your comments and suggestions. (And sorry for my late reply).
> On Jul 28, 2022, at 3:26 AM, Richard Biener wrote:
>
> On Tue, 19 Jul 2022, Qing Zhao wrote:
>
>> From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001
>>
> On Aug 1, 2022, at 3:13 AM, Richard Biener wrote:
>
> On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>>
>>
>>> On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
>>>
>>> On Tue, 19 Jul 2022, Qing Zhao wrote:
>>>
>>>>
> On Aug 1, 2022, at 3:38 AM, Richard Biener wrote:
>
> On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> Thanks a lot for your comments and suggestions. (And sorry for my late
>> reply).
>>
>>> On Jul 28, 2022, at 3:26 AM,
> On Aug 2, 2022, at 3:03 AM, Richard Biener wrote:
>
> On Mon, 1 Aug 2022, Qing Zhao wrote:
>
>>
>>
>>> On Aug 1, 2022, at 3:38 AM, Richard Biener wrote:
>>>
>>> On Fri, 29 Jul 2022, Qing Zhao wrote:
>>>
>>>> Hi,
Hi, Nathan,
I am adding a new bitfield “decl_not_flexarray” in “tree_decl_common”
(gcc/tree-core.h) for the new gcc feature -fstrict-flex-arrays.
diff --git a/gcc/tree-core.h b/gcc/tree-core.h
index ea9f281f1cc..458c6e6ceea 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1813,7 +18
Thanks a lot for your testing on Linux Kernel.
Will work on the version 3 of this patch soon.
Qing
> On Aug 2, 2022, at 11:30 AM, Kees Cook wrote:
>
> On Tue, Jul 19, 2022 at 02:11:19PM +0000, Qing Zhao wrote:
>> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:
Hi, Joseph,
When -std=c89 or -std=gnu89 present in the command line, in C FE, which flags
should be
checked to decide it’s -std=c89 or -std=gnu89?
Thanks a lot for your help.
Qing
> On Aug 2, 2022, at 12:34 PM, Marek Polacek wrote:
>
> On Tue, Aug 02, 2022 at 04:19:56PM +0000, Qing Zhao via Gcc-patches wrote:
>> Hi, Joseph,
>>
>> When -std=c89 or -std=gnu89 present in the command line, in C FE, which
>> flags should be
>> checke
Hi,
My private cc1 issued the following warning:
[opc@qinzhao-ol8u3-x86 gcc]$ sh t
cc1: warning: ‘-fstrict-flex-arrays’ is not supported with a ISO C before C99,
ignored
I’d like to add a testing case for this warning into gcc.dg directory, however,
I cannot find a proper
testing directive to
Never mind, just found how to do this:
/* { dg-warning "'-fstrict-flex-arrays' is not supported with a ISO C before
C99, ignored" "" { target *-*-* } 0 } */
And worked.
thanks.
Qing
> On Aug 3, 2022, at 2:52 PM, Qing Zhao via Gcc-patches
> wrote:
>
Hi,
As mentioned in the bug report, I reopened this bug since the previous patch:
commit r13-1875-gff26f0ba68fe6e870f315d0601b596f889b89680
Author: Richard Biener
Date: Thu Jul 28 10:07:32 2022 +0200
middle-end/106457 - improve array_at_struct_end_p for array objects
Array references
> On Aug 11, 2022, at 3:40 AM, Richard Biener wrote:
>
> On Wed, 10 Aug 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> As mentioned in the bug report, I reopened this bug since the previous patch:
>>
>> commit r13-1875-gff26f0ba68fe6e870f315d0601b596f88
> On Aug 2, 2023, at 2:25 AM, Martin Uecker wrote:
>
> Am Dienstag, dem 01.08.2023 um 15:45 -0700 schrieb Kees Cook:
>> On Mon, Jul 31, 2023 at 08:14:42PM +, Qing Zhao wrote:
>>> /* In general, Due to type casting, the type for the pointee of a pointer
>>>
> On Aug 1, 2023, at 6:45 PM, Kees Cook wrote:
>
> On Mon, Jul 31, 2023 at 08:14:42PM +0000, Qing Zhao wrote:
>> /* In general, Due to type casting, the type for the pointee of a pointer
>> does not say anything about the object it points to,
>> So, __builtin_o
> On Aug 1, 2023, at 10:31 AM, Martin Uecker wrote:
>
> Am Dienstag, dem 01.08.2023 um 13:27 + schrieb Qing Zhao:
>>
>>> On Aug 1, 2023, at 3:51 AM, Martin Uecker via Gcc-patches
>>> wrote:
>>>
>
>
>>>> Hi Martin,
&
Ping.
This is a very simple patch to correct a URL address in GCC13’s changes.html.
Currently, it’s pointing to a wrong address.
Okay for committing?
> On Jul 21, 2023, at 3:02 PM, Qing Zhao wrote:
>
> Hi,
>
> In the current GCC13 release note, the URL to the option -fstrict-
Ping…
thanks.
Qing
> On Jul 10, 2023, at 3:11 PM, Qing Zhao wrote:
>
> Hi,
>
> This is the change for the GCC14 releaes Notes on the deprecating of a C
> extension about flexible array members.
>
> Okay for committing?
>
> thanks.
>
> Qing
>
>
> On Aug 3, 2023, at 3:10 AM, Richard Biener wrote:
>
> On Mon, Jul 10, 2023 at 9:12 PM Qing Zhao via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> This is the change for the GCC14 releaes Notes on the deprecating of a C
>> extension about flexible
When adding the option -Wflex-array-member-not-at-end in the commit
https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html
the documentation for this new option was missing.
This patch is to add the documentation for this warning option.
bootstrapped and also checked the documentation, no i
> On Aug 3, 2023, at 12:15 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-02 10:02, Qing Zhao wrote:
>> /*when checking the observed access p->array, we only have info on the
>> observed access, i.e, the TYPE_SIZE info from the access. We don't have
&g
:
>
> On 2023-08-03 12:43, Qing Zhao wrote:
>>> Surely we could emit that for __bdos(q->array, 0) though, couldn't we?
>> For __bdos(q->array, 0), we only have the access info for the sub-object
>> q->array, we can surely decide the size of the sub-obje
> On Aug 3, 2023, at 1:51 PM, Kees Cook wrote:
>
> On August 3, 2023 10:34:24 AM PDT, Qing Zhao wrote:
>> One thing I need to point out first is, currently, even for regular fixed
>> size array in the structure,
>> We have this same issue, for example:
>>
&
t that has
TYPE struct fix?
If the answer is YES, then the current__builtin_object_size algorithm can be
improved to determine __builtin_object_size(p->array, 0) with the TYPE of the
struct fix.
Qing
> On Aug 3, 2023, at 1:34 PM, Qing Zhao via Gcc-patches
> wrote:
>
> One
> On Aug 4, 2023, at 3:38 AM, Kees Cook wrote:
>
> On Thu, Aug 03, 2023 at 09:31:24PM +0000, Qing Zhao wrote:
>> So, the basic question is:
>>
>> Given the following:
>>
>> struct fix {
>> int others;
>> int array[10];
>> }
Thanks.
I just updated the doc per your suggestion and committed as:
https://gcc.gnu.org/pipermail/gcc-cvs/2023-August/387588.html
Qing
> On Aug 3, 2023, at 1:29 PM, Joseph Myers wrote:
>
> On Thu, 3 Aug 2023, Qing Zhao via Gcc-patches wrote:
>
>> +@opindex Wflex-array
> On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-03 13:34, Qing Zhao wrote:
>> One thing I need to point out first is, currently, even for regular fixed
>> size array in the structure,
>> We have this same issue, for example:
>>
> On Aug 4, 2023, at 10:42 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-04 10:40, Siddhesh Poyarekar wrote:
>> On 2023-08-03 13:34, Qing Zhao wrote:
>>> One thing I need to point out first is, currently, even for regular fixed
>>> size array in the structure,
> On Aug 4, 2023, at 12:36 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-04 11:27, Qing Zhao wrote:
>>> On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-08-03 13:34, Qing Zhao wrote:
>>>> One thing I need to point
> On Aug 4, 2023, at 3:09 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-04 15:06, Qing Zhao wrote:
>>> Yes, that's what I'm thinking.
>>>
>>>>> so `q` must be pointing to a single element. So you could deduce:
>>>>>
>&
description of this work on:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619708.html
Okay for committing?
thanks.
Qing
Qing Zhao (3):
Provide counted_by attribute to flexible array member field (PR108896)
Use the counted_by atribute info in builtin object size [PR108896]
Use t
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the 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
inf
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the counted_by
attribute info.
* tree.cc (component_ref_has_counted_by_p): New function.
(component_ref_get_counted_by): New function.
* tree.h (component_ref_has_counted_by_p):
gcc/c-family/ChangeLog:
PR C/108896
* c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute
information.
gcc/testsuite/ChangeLog:
PR C/108896
* gcc.dg/ubsan/flex-array-counted-by-bounds.c: New test.
* gcc.dg/ubsan/flex-array-counted-by-bou
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
Okay for committing?
thanks.
Qing
==
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecatin
> On Aug 7, 2023, at 12:16 PM, Kees Cook wrote:
>
> On Fri, Aug 04, 2023 at 07:44:28PM +0000, Qing Zhao wrote:
>> This is the 2nd version of the patch, per our discussion based on the
>> review comments for the 1st version, the major changes in this version
>> are:
a; short b; char t[3]; };
>
> This would make the most sense to me, but it has 12 bytes
> because the padding is according to the usual alignment
> rules.
>
>
> Martin
>
>
>
> Am Montag, dem 07.08.2023 um 09:16 -0700 schrieb Kees Cook:
>> On Fri, Aug
> On Aug 9, 2023, at 12:21 PM, Michael Matz wrote:
>
> Hello,
>
> On Wed, 9 Aug 2023, Qing Zhao wrote:
>
>> Although this is an old FAM related issue that does not relate to my current
>> patch
>> (and might need to be resolved in a separate patch). I t
structure with FAM cannot be an element of an
array,
the tailing padding might not be necessary?
Qing
>
>
> Martin
>
>
>
> Am Montag, dem 07.08.2023 um 09:16 -0700 schrieb Kees Cook:
>> On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote:
>>> This is the 2nd
> On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
>
> Am Mittwoch, dem 09.08.2023 um 20:10 + schrieb Qing Zhao:
>>
>>> On Aug 9, 2023, at 12:21 PM, Michael Matz wrote:
>
> ...
>>
>> By definition, the sizeof() of a struct with FAM might not b
t;> On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
>>>>> Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao:
>>>>>>
>>>>>>> On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
>>>>>>>
>&g
> On Aug 10, 2023, at 12:39 PM, Jakub Jelinek wrote:
>
> On Thu, Aug 10, 2023 at 12:30:06PM -0400, Siddhesh Poyarekar wrote:
>> The definition of __bos/__bdos allows us the freedom to *estimate* rather
>> than be precise, so I'd go for sizeof(x) + N * sizeof(*x.a) since it's bound
>> to give t
Hi, Sid,
For the following testing case:
#include
#define noinline __attribute__((__noinline__))
static void noinline alloc_buf_more (int index)
{
struct annotated {
long foo;
char b;
char array[index];
long c;
} q, *p;
p = &q;
printf("the__bdos of p->array whole max
Thanks.
I just filed a PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030 to record
this issue and added you to the CC list.
Qing
> On Aug 15, 2023, at 6:57 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-14 19:12, Qing Zhao wrote:
>> Hi, Sid,
>> For the following test
Jakub and Sid,
During my study, I found an interesting behavior for the following small
testing case:
#include
#include
struct fixed {
size_t foo;
char b;
char array[10];
} q = {};
#define noinline __attribute__((__noinline__))
static void noinline bar ()
{
struct fixed *p = &q;
FYI, I filed a new PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111040
to record this issue.
Qing
> On Aug 16, 2023, at 11:59 AM, Qing Zhao via Gcc-patches
> wrote:
>
> Jakub and Sid,
>
> During my study, I found an interesting behavior for the following sma
Hi,
After some more studying and consideration, the following is my thoughts:
For a structure with FMA annotated with counted_by attribute: (the following
small example)
struct annotated {
size_t foo;
char b;
char array[] __attribute__((counted_by (foo)));
};
#def
]$
Qing
> On Aug 17, 2023, at 2:38 AM, Kees Cook wrote:
>
> On Wed, Aug 16, 2023 at 10:31:30PM -0700, Kees Cook wrote:
>> On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote:
>>> This is the 2nd version of the patch, per our discussion based on the
>>> re
> On Aug 17, 2023, at 7:00 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-16 11:59, Qing Zhao wrote:
>> Jakub and Sid,
>> During my study, I found an interesting behavior for the following small
>> testing case:
>> #include
>> #include
>> struct fi
> On Aug 17, 2023, at 1:49 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 09:58, Qing Zhao wrote:
>>> So this is a (sort of) known issue, which necessitated the early_objsz pass
>>> to get an estimate before a subobject reference was optimized to a MEM_REF.
> On Aug 17, 2023, at 3:59 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 15:27, Qing Zhao wrote:
>>> Yes, that's it. Maybe it's more correct if instead of MAX_EXPR if for
>>> OST_MINIMUM we stick with the early_objsz answer if it's non-zero.
> On Aug 17, 2023, at 4:57 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 16:23, Qing Zhao wrote:
>>>> Then, I think whatever MIN or MAX, the early phase has more precise
>>>> information than the later phase, we should use its result if it’s NOT
>&g
> On Aug 17, 2023, at 5:32 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 17:25, Qing Zhao wrote:
>>> It's not exactly the same issue, the earlier discussion was about choosing
>>> sizes in the same pass while the current one is about choosing between
&g
> On Jun 15, 2023, at 6:48 PM, Joseph Myers wrote:
>
> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> B. The argument of the new attribute “counted_by” is an identifier that can
>> be
>> accepted by “c_parser_attribute_arguments”:
>>
>&
> On Jun 16, 2023, at 3:21 AM, Martin Uecker wrote:
>
> Am Donnerstag, dem 15.06.2023 um 16:55 + schrieb Joseph Myers:
>> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>>
> ...
>>> 1. Update the routine “c_parser_postfix_expression” (is this the
Hi, Alexandre,
> On Jun 16, 2023, at 3:26 AM, Alexandre Oliva wrote:
>
> Hello, Qing,
>
> On Oct 27, 2022, Qing Zhao wrote:
> <https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604480.html>
>
>> On Oct 26, 2022, at 5:29 PM, Alexandre Oliva wrote:
>&
> On Jun 16, 2023, at 1:07 PM, Martin Uecker wrote:
>
> Am Freitag, dem 16.06.2023 um 16:21 + schrieb Joseph Myers:
>> On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote:
>>
Note that no expressions can start with the '.' token at present. As soon
as you invent a new kin
have been
approved already.
for the patch 3/3, I will wait for several days, if there is no
objection or new comments, I will commit it the end of this week.
Please let me know if you have comments and suggestions.
thanks.
Qing
Qing Zhao (3):
Introduce IR bit TYPE_INCLUDES_FLEXARRAY for the
on a structure with a C99 flexible array member being nested in
another structure.
"The GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are two situations:
* A
__builtin_object_size should treat struct with TYPE_INCLUDES_FLEXARRAY as
flexible size.
gcc/ChangeLog:
PR tree-optimization/101832
* tree-object-size.cc (addr_object_size): Handle structure/union type
when it has flexible size.
gcc/testsuite/ChangeLog:
PR tree-o
on a structure with a C99 flexible array member being nested in
another structure
GCC extension accepts the case when a struct with a flexible array member
is embedded into another struct or union (possibly recursively) as the last
field.
This patch is to introduce the IR bit TYPE_INCLUDES_FLEXARR
> On Jun 16, 2023, at 5:35 PM, Joseph Myers wrote:
>
> On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>>> So for
>>>
>>> struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; };
>>>
>>> one knows during p
Hi, Alexandre,
>
> diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
> index 22e240a3c2a55..f9cc609b54d94 100644
> --- a/gcc/c/c-typeck.cc
> +++ b/gcc/c/c-typeck.cc
> @@ -2226,6 +2226,35 @@ convert_lvalue_to_rvalue (location_t loc, struct
> c_expr exp,
> exp.value = convert (build_qualified
Hi, Alexandre,
> On Jun 21, 2023, at 9:16 PM, Alexandre Oliva wrote:
>
> Hello, Qing,
>
> On Jun 16, 2023, Qing Zhao wrote:
>
>> As I mentioned in the previous round of review, I think that the
>> documentation
>> might need to add more details on what
> On Jun 21, 2023, at 10:35 PM, Alexandre Oliva wrote:
>
> On Jun 21, 2023, Qing Zhao wrote:
>
>> I see that you have testing case to check the above built_in_trap call
>> is generated by FE.
>> Do you have a testing case to check the trap is happening at runt
> On Jun 23, 2023, at 7:27 PM, Alexandre Oliva wrote:
>
> On Jun 23, 2023, Qing Zhao via Gcc-patches wrote:
>
>> It’s better to add this definition earlier in the list of the “three
>> basic values”, to make it “four basic values”, like the following:
>
> Oh, m
Hi, Alexandre,
> On Jun 23, 2023, at 10:38 PM, Alexandre Oliva wrote:
>
>> For normal Boolean variables, 0x00 is false, this is a reasonable init
>> value with zero-initialization.
>
> *nod*. I was surprised by zero initialization of (non-hardened)
> booleans even when pattern is requested, bu
might need to
extend the C FE to accept ".count” in the future.
Let me know if you have further comments and suggestions.
thanks.
Qing
> On Jun 20, 2023, at 3:40 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Jun 16, 2023, at 5:35 PM, Joseph Myers wrote:
Hi, Alexandre,
Thanks a lot for the work. I think that this will be a valuable feature to be
added for GCC’s security functionality.
I have several questions on this patch:
1. The implementation of register scrubbing, -fzero-call-used-regs, is to
insert the register zeroing sequence in th
> On Jun 28, 2023, at 3:26 AM, Alexandre Oliva wrote:
>
> I'd probably have arranged for the front-end to create the initializer
> value, because expansion time is too late to figure it out: we may not
> even have the front-end at hand any more, in case of lto compilation.
>>>
On Jun 28, 2023, Qing Zhao wrote:
>
>> In summary, Ada’s Boolean variables (whether it’s hardened or not) are
>> represented as
>> enumeration types in GNU IR.
>
> Not quite. Only boolean types with representation clauses are. Those
> without (such as Standard.Boolean
n on this?
thanks.
Qing
> On May 26, 2023, at 4:40 PM, Kees Cook wrote:
>
> On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote:
>> GCC will pass the number of elements info from the attached attribute to
>> both
>> __builtin_dynamic_object_size and bound
> On Jul 6, 2023, at 5:10 PM, Martin Uecker wrote:
>
> Am Donnerstag, dem 06.07.2023 um 18:56 + schrieb Qing Zhao:
>> Hi, Kees,
>>
>> I have updated my V1 patch with the following changes:
>> A. changed the name to "counted_by"
>> B. ch
ser errors during compilation time, or the sanitizer
option '-fsanitize=counted-by-attribute' to detect such user errors
during runtime.
=====
Qing
> On Jul 7, 2023, at 11:47 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Jul 6, 2023, at 5:10
Hi,
This is the change for the GCC14 releaes Notes on the deprecating of a C
extension about flexible array members.
Okay for committing?
thanks.
Qing
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C
extension about flexible array members.
---
htdocs/gcc-14/ch
Thank you for fixing this issue.
Qing
> On Feb 15, 2023, at 2:19 PM, Hans-Peter Nilsson wrote:
>
> Tested for cris-elf. Ok to commit?
>
> -- >8 --
> Looks like there's a failed assumption that
> sizeof (union U { char u1[5]; int u2; float u3; }) == 8.
> However, for "packed" targets like cris
Ping…
Qing
> On Feb 10, 2023, at 7:50 PM, Qing Zhao wrote:
>
> These are the 3rd version of the patches for PR101832, to fix
> builtin_object_size to correctly handle component_ref to a
> structure/union field that includes a flexible array member.
>
> also includes a doc
801 - 900 of 1564 matches
Mail list logo
