> On Apr 7, 2025, at 10:31, Michael Matz wrote:
>
> Hello,
>
> On Mon, 7 Apr 2025, Martin Uecker wrote:
>
>>> So, what specifically would the two attributes do different? FWIW: what
>>> worries me about accepting a generic expression in counted_by, that isn't
>>> prefixed by a (possibly e
> On Mar 28, 2025, at 08:51, Yeoul Na wrote:
>
>
>
>> On Mar 27, 2025, at 9:17 AM, Qing Zhao wrote:
>>
>> Yeoul,
>>
>> Thanks for the writeup.
>>
>> So, basically, This writeup insisted on introducing a new “structure scope”
>>
Jakub,
Thank you for the comments.
> On Apr 2, 2025, at 02:48, Jakub Jelinek wrote:
>
> On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote:
>> On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote:
>>> Am Dienstag, dem 01.04.2025 um 15:01 + schrieb Qing Zh
> On Apr 4, 2025, at 04:59, Bill Wendling wrote:
>
> On Thu, Apr 3, 2025 at 9:54 AM Kees Cook wrote:
>> On Wed, Apr 02, 2025 at 09:16:47PM +, Qing Zhao wrote:
>>> Hi, Bill,
>>>
>>> Thanks for the summary.
>>>
>>> I think that
> On Apr 4, 2025, at 11:54, Martin Uecker wrote:
>
> Am Freitag, dem 04.04.2025 um 15:22 + schrieb Qing Zhao:
>> Hi, Michael,
>>
>> Thanks a lot for raising these questions for the parser implementation of
>> the new syntax.
>>
>> I sta
So, a different attribute name “counted_by_exp” might be better?
Qing
> On Apr 4, 2025, at 11:55, Michael Matz wrote:
>
> Hello,
>
> On Fri, 4 Apr 2025, Qing Zhao wrote:
>
>> A:
>> constexpr int len = 20;
>> struct s {
>> int len;
>> int *
Hi, Michael,
Thanks a lot for raising these questions for the parser implementation of the
new syntax.
I started thinking about how to implement this new syntax inside counted_by
attriubte
In GCC C FE. Since I have very little experience with any parser, I do want to
know
any potential imple
CC’ing gcc alias as well.
Hi, Yeoul,
I think the key for when to use the forward declaration syntax is:
When there is only one single identifier as the argument of counted_by
attribute,
There will be no possibility of scope conflict between different identifiers
inside
the counted_by attrib
> On Apr 2, 2025, at 14:35, Bill Wendling wrote:
>
> On Tue, Apr 1, 2025 at 11:49 PM Jakub Jelinek wrote:
>> On Tue, Apr 01, 2025 at 05:13:46PM -0700, Bill Wendling wrote:
>>> On Tue, Apr 1, 2025 at 8:29 AM Martin Uecker wrote:
>>>> Am Dienstag, dem 01.04.2025 um
> On Apr 4, 2025, at 12:51, Michael Matz wrote:
>
> Hello,
>
> On Fri, 4 Apr 2025, Qing Zhao wrote:
>
>> So, a different attribute name “counted_by_exp” might be better?
>
> I would prefer Martins empty-decl idea to that: "counted_by(;len+0)"
>
> On Apr 4, 2025, at 13:09, Martin Uecker wrote:
>
> Am Freitag, dem 04.04.2025 um 18:51 +0200 schrieb Michael Matz:
>> Hello,
>>
>> On Fri, 4 Apr 2025, Qing Zhao wrote:
>>
>>> So, a different attribute name “counted_by_exp” might be better?
>&g
> On Apr 8, 2025, at 13:13, Siddhesh Poyarekar wrote:
>
> On 2025-04-08 12:41, Qing Zhao wrote:
>> For the following small example:
>> [ counted_by_whole]$ cat t.c
>> #include
>> #include
>> struct annotated {
>> size_t count;
>> char
. fix PR117375 (Bug in tree-ssa-sink.cc);
B. documentation clarification;
C. Add all the duplicated PRs in the commit comments;
4. Bootstrap GCC with the new -fdiagnostics-details on by default (Init (1)).
exposed some ICE similar as PR117375 in tree-ssa-sink.cc, fixed.
Qing Zhao (3):
Pr
Hi, Sid:
> On Apr 10, 2025, at 06:56, Siddhesh Poyarekar wrote:
>
>
>> Maybe you could add it when a pointer to an annotated
>> struct is passed as parameter, but also there it is not
>> clear to me that we might want to materialize new
>> accesses to the struct at this point.
>> An alternative
>>
>> Thanks, will file bugs and fix them first.
>
> I filed two bugs against GCC15:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119716
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119717
>
> And assigned to myself.
Both the above were resolved.
Qing
This is the 2nd version of the patch, the change is to replace "FALSE" with
"false" per Marek's comments.
C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
In c_fully_fold, it assumes that operands of function calls have already
been folded. However, when we build call to
Thanks.
Pushed to trunk.
Qing
> On Apr 15, 2025, at 14:56, Marek Polacek wrote:
>
> On Tue, Apr 15, 2025 at 06:46:26PM +0000, Qing Zhao wrote:
>> This is the 2nd version of the patch, the change is to replace "FALSE" with
>> "false" per Marek's
> On Apr 14, 2025, at 16:35, Marek Polacek wrote:
>
> On Mon, Apr 14, 2025 at 08:28:55PM +0000, Qing Zhao wrote:
>> C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
>> In c_fully_fold, it assumes that operands of function calls have already
&g
> On Apr 10, 2025, at 15:22, Qing Zhao wrote:
>
>
>
>> On Apr 10, 2025, at 13:43, Martin Uecker wrote:
>>
>> Am Donnerstag, dem 10.04.2025 um 17:05 + schrieb Qing Zhao:
>>> Hi, Martin,
>>>
>>> Thanks
Hi, Bill,
Thanks for your new proposal.
If I understand correctly, this new proposal basically is back to one of our
previous proposal:
Adding a new structure scoping for counted_by attribute into C;
With this approach, there is one new structure scoping added to C, and this new
scope
will
C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
In c_fully_fold, it assumes that operands of function calls have already
been folded. However, when we build call to .ACCESS_WITH_SIZE, all its
operands are not fully folded. therefore the C FE specific operator is
passed t
> On Apr 15, 2025, at 16:35, Kees Cook wrote:
>
> On Tue, Apr 15, 2025 at 09:07:44PM +0200, Martin Uecker wrote:
>> Am Dienstag, dem 15.04.2025 um 14:50 +0200 schrieb Michael Matz:
>>> Hello,
>> ...
>>
struct A {
int *buf __counted_by(len); // 'len' *must* be in the struct.
in
Hi,
I have met the following issue when I tried to implement the following into
tree-object-size.cc:
(And this took me quite some time, still don’t know what’s the best solution)
> On Apr 16, 2025, at 10:46, Qing Zhao wrote:
>
> 3. When generating the reference to the field membe
Current array bound checker only instruments ARRAY_REF, and the INDEX
information is the 2nd operand of the ARRAY_REF.
When extending the array bound checker to pointer references with
counted_by attributes, the hardest part is to get the INDEX of the
corresponding array ref from the offset comput
Hi,
This is the 2nd version of the patch set to extend "counted_by" attribute
to pointer fields of structures.
the first version was submitted 3 months ago on 1/16/2025, and triggered
a lot of discussion on whether we need a new syntax for counted_by
attribute.
https://gcc.gnu.org/pipermail/gcc
o, the counted_by information is not useful for the
__builtin_dynamic_object_size.
But I am not sure whether the counted_by still can be used for bound sanitizer?
Thanks for suggestions and help.
Qing
> On Apr 23, 2025, at 15:45, Qing Zhao wrote:
>
> Hi,
>
> This is the 2nd ver
> On Apr 24, 2025, at 13:07, Kees Cook wrote:
>
> On Thu, Apr 24, 2025 at 04:36:14PM +0000, Qing Zhao wrote:
>>
>>> On Apr 24, 2025, at 11:59, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 24.04.2025 um 15:15 + schrieb Qing Zhao:
>>
> On Apr 24, 2025, at 19:56, Kees Cook wrote:
>
>
>
> On April 24, 2025 1:44:23 PM PDT, Qing Zhao wrote:
>>
>>
>>> On Apr 24, 2025, at 15:43, Bill Wendling wrote:
>>>
>>> On Thu, Apr 24, 2025 at 8:15 AM Qing Zhao wrote:
>>
For example:
struct PP {
size_t count2;
char other1;
char *array2 __attribute__ ((counted_by (count2)));
int other2;
} *pp;
specifies that the "array2" is an array that is pointed by the
pointer field, and its number of elements is given by the field
"count2" in the same structure.
gcc/c-
gcc/c/ChangeLog:
* c-typeck.cc (build_counted_by_ref): Handle pointers with counted_by.
(build_access_with_size_for_counted_by): Likewise.
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): Handle pointers
with counted_by.
(collect_object
> On Apr 24, 2025, at 11:59, Martin Uecker wrote:
>
> Am Donnerstag, dem 24.04.2025 um 15:15 + schrieb Qing Zhao:
>> Hi,
>>
>> Kees reported a segmentation failure when he used the patch to compiler
>> kernel,
>> and the reduced the testi
> On Apr 24, 2025, at 15:43, Bill Wendling wrote:
>
> On Thu, Apr 24, 2025 at 8:15 AM Qing Zhao wrote:
>>
>> Hi,
>>
>> Kees reported a segmentation failure when he used the patch to compiler
>> kernel,
>> and the reduced the testing case is
> On Apr 24, 2025, at 13:07, Kees Cook wrote:
>
> On Thu, Apr 24, 2025 at 04:36:14PM +0000, Qing Zhao wrote:
>>
>>> On Apr 24, 2025, at 11:59, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 24.04.2025 um 15:15 + schrieb Qing Zhao:
>>
> On Apr 25, 2025, at 13:18, Kees Cook wrote:
>
> On Fri, Apr 25, 2025 at 04:56:52PM +0000, Qing Zhao wrote:
>>
>>
>>> On Apr 24, 2025, at 13:07, Kees Cook wrote:
>>>
>>> On Thu, Apr 24, 2025 at 04:36:14PM +, Qing Zhao wrote:
>>>
ution)
>>
>>> On Apr 16, 2025, at 10:46, Qing Zhao wrote:
>>>
>>> 3. When generating the reference to the field member in tree-object-size,
>>> we should guard this reference with a checking
>>> on the pointer to the structure is valid. i.e:
&
> On Apr 24, 2025, at 14:31, Kees Cook wrote:
>
> On Thu, Apr 24, 2025 at 06:06:03PM +0000, Qing Zhao wrote:
>>
>>
>>> On Apr 24, 2025, at 13:07, Kees Cook wrote:
>>>
>>> On Thu, Apr 24, 2025 at 04:36:14PM +, Qing Zhao wrote:
>>>
> On May 25, 2023, at 5:02 PM, Joseph Myers wrote:
>
> What happens if the field giving the number of elements is in a contained
> anonymous structure or union?
>
> struct s {
> struct { size_t count; };
> int array[] __attribute__ ((element_count ("count")));
> };
>
> This ought to work -
Thank you for the suggestion.
> On May 26, 2023, at 1:59 PM, Joseph Myers wrote:
>
> On Thu, 25 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> On May 25, 2023, at 4:51 PM, Joseph Myers wrote:
>>>
>>> The documentation in this case is OK, though clai
> On May 26, 2023, at 2:15 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> What if the string is a wide string? I don't expect that to work (either
>>> as a matter of interface design, or in the present code), but I
> On May 26, 2023, at 4:12 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>> Another question: is it better for me to rearrange the Patch 1/2 and Patch
>> 2/2 a little bit,
>> to put the FE , doc change and corresponding
> On May 26, 2023, at 4:40 PM, Kees Cook wrote:
>
> On Thu, May 25, 2023 at 04:14:47PM +0000, Qing Zhao wrote:
>> GCC will pass the number of elements info from the attached attribute to
>> both
>> __builtin_dynamic_object_size and bounds sanitizer to check the
ame.
Thanks a lot for your suggestions and comments.
Qing
>
> Martin
>
>
>
>
> Am Donnerstag, dem 25.05.2023 um 16:14 + schrieb Qing Zhao:
>> 2023-05-17 Qing Zhao
>>
>> gcc/ChangeLog:
>>
>> PR C/108896
>>
Hi,
This is the 8th version of the patch, which rebased on the latest trunk.
This is an important patch needed by Linux Kernel security project.
compared to the 8th version, the Only change is in PATCH 2/2 (per
Joseph's comment):
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 17e
Richard or Jakub,
could you please review this patch and see whether it's Okay to commit?
thanks a lot.
Qing
===
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively) as the
Joseph,
could you please review this patch and see whether it's Okay for commit
now?
thanks a lot for all your comments and suggestions for this patch.
Qing.
==
on a structure with a C99 flexible array member being nested in
another structure.
"The GCC exte
> On May 26, 2023, at 12:12 PM, Kees Cook wrote:
>
> On Thu, May 25, 2023 at 04:14:47PM +0000, Qing Zhao wrote:
>> This patch set introduces a new attribute "element_count" to annotate bounds
>> for C99 flexible array member.
>
> Thank you for this work!
Ping on this patch.
The C FE and Doc changes has been approved.
Please help to review and approve the Middle-end change.
Or provide guide on how to move this patch forward.
Thanks a lot for the help.
Qing
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle.com>>
Subjec
Hi, Joseph,
A question here: can an identifier in C be a wide char string?
Qing
> On May 26, 2023, at 2:15 PM, Joseph Myers wrote:
>
> On Fri, 26 May 2023, Qing Zhao via Gcc-patches wrote:
>
>>> What if the string is a wide string? I don't expect that to work (
> On Jun 7, 2023, at 4:53 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Hi, Joseph,
>>
>> A question here: can an identifier in C be a wide char string?
>
> Identifiers and strings are different kinds of tokens; a
> On Jun 7, 2023, at 6:05 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Are you suggesting to use identifier directly as the argument of the
>> attribute?
>> I tried this in the beginning, however, the current parser for
for commit to trunk?
Thanks a lot!
Qing
> On Jun 5, 2023, at 11:12 AM, Qing Zhao via Gcc-patches
> wrote:
>
> Ping on this patch.
>
> The C FE and Doc changes has been approved.
> Please help to review and approve the Middle-end change.
>
> Or provide guide on how
your help.
Qing
> On Jun 7, 2023, at 6:05 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Are you suggesting to use identifier directly as the argument of the
>> attribute?
>> I tried this in the beginning, however, the current p
> On Jun 15, 2023, at 12:55 PM, Joseph Myers wrote:
>
> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Comparing B with A, I don’t see too much benefit, either from
>> user-interface point of view, or from implementation point of view.
>>
>> F
> On Jul 13, 2023, at 4:31 PM, Kees Cook wrote:
>
> In the bug, the problem is that "p" isn't known to be allocated, if I'm
> reading that correctly?
I think that the major point in PR109557
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557):
for the following pointer p.3_1,
p.3_1 = p;
> On Jul 17, 2023, at 7:40 PM, Kees Cook wrote:
>
> On Mon, Jul 17, 2023 at 09:17:48PM +0000, Qing Zhao wrote:
>>
>>> On Jul 13, 2023, at 4:31 PM, Kees Cook wrote:
>>>
>>> In the bug, the problem is that "p" isn't known to be allocate
> 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
601 - 700 of 1419 matches
Mail list logo
