Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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 -

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

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

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

> 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

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> 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 bounds sanitizer to check the out-of-bounds >> or dynamic ob

Re: [V1][PATCH 2/3] Use the element_count atribute info in builtin object size [PR108896].

> On May 27, 2023, at 6:20 AM, Martin Uecker wrote: > > > Thank you for working on this! > > > Here are a couple of comments: > > How is the size for an object with FAM defined? Right now, with the attribute approach, the sizeof for the object with FAM is not impacted, and kept the same

[V9][PATCH 0/2] Accept and Handle the case when a structure including a FAM nested in another structure

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

[V9][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

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

[V9][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

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

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> On May 26, 2023, at 12:12 PM, Kees Cook wrote: > > On Thu, May 25, 2023 at 04:14:47PM +, 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! I'm really excited to start using it

Ping: Fwd: [V9][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

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>> Subject: [V9][PAT

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

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 (

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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

Ping * 2 : Fwd: [V9][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

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

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

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

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> 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;

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> 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 wrote: >>> >>> In the bug, the problem is that "p" isn't known to be allocated, if I'm >>> reading that correctly? >> >> I think that

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> 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 +, Qing Zhao wrote: > On Jul 13, 2023, at 4:31 PM, Kees

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> 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

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

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

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

>> >> 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

[PATCH] gcc-13/changes.html: Add and fix URL to -fstrict-flex-array option.

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

Re: [C PATCH]: Add Walloc-type to warn about insufficient size in allocations

> 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

One question on the source code of tree-object-size.cc

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

Re: One question on the source code of tree-object-size.cc

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 portion of the routine >>> “addr_object_size” of

Re: One question on the source code of tree-object-size.cc

> 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 smaller one between these two, >> i.e, the

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

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: > >

Re: One question on the source code of tree-object-size.cc

> 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 >>> “addr_object_size” of gcc/tree-object-size.c

Re: One question on the source code of tree-object-size.cc

Okay. This previous small example was used to show the correct behavior of __bos for Fixed arrays when the allocation size and the TYPE_SIZE are mismatched. Now we agreed on the correct behavior for each of the cases for the fixed array. Since the new “counted_by” attribute is mainly a comple

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

> 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 28, 2022, at 2:22 PM, Jakub Jelinek wrote: > >

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

> 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

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

> On Jun 30, 2022, at 1:03 PM, Jakub Jelinek wrote: > > On Thu, Jun 30, 2022 at 03:31:00PM +, 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: >> >> 1. What do you mean by “cv variants” of a str

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

> 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 wrote: > No, that’s not true. A FIELD_DELC is only share

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

> 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 wrote: > On Jun 30, 2022, at 1:03 PM, Jakub

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

> On Jul 1, 2022, at 8:59 AM, Jakub Jelinek wrote: > > On Fri, Jul 01, 2022 at 12:55:08PM +, 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 checking into FE, and leaving the oth

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

(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, 2022, at 8:59 AM, Jakub Jelinek wrote: On Fr

Re: [GCC 13][PATCH] PR101836: Add a new option -fstrict-flex-array[=n] and use it in __builtin_object_size

> 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: >>> >>> On Fri, Jul 1, 2022 at 5:32 PM Martin Sebor

[GCC13][Patch][V2][0/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

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]

[GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

>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 corresponding

[GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

>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 of a struc

Re: [GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

> 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] Use new flag DECL_NOT_FLEXARRAY in __b

Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

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 >> From: Qing Zhao >> Date: Mo

Re: [GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

> 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: >>> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001 F

Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

> 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, Richard Biener wrote: >>> >>> On Tue, 19 Jul 2022, Qi

Re: [GCC13][Patch][V2][1/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

> 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, Richard, Thanks a lot for your comments and suggestions. (And so

Where in C++ module streaming to handle a new bitfield added in "tree_decl_common"

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

Re: [GCC13][Patch][V2][2/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

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 +, Qing Zhao wrote: >> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001 >> From: Qi

How to check -std=c89 or -std=gnu89 is set in C FE?

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

Re: How to check -std=c89 or -std=gnu89 is set in C FE?

> 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

HELP!!How to add a testing case to check a compilation time warning for "cc1"

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

Re: HELP!!How to add a testing case to check a compilation time warning for "cc1"

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: >

[GCC13][Patch][PR106457]improve array_at_struct_end_p for array objects (PR106457)

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

Re: [GCC13][Patch][PR106457]improve array_at_struct_end_p for array objects (PR106457)

> 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-gff26f0ba68fe6e870f315d0601b596f889b89680 >> Author: Richard Biener >> Date: Th

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> 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 >>> does not say anything about the

Re: [V1][PATCH 0/3] New attribute "element_count" to annotate bounds for C99 FAM(PR108896)

> On Aug 1, 2023, at 6:45 PM, Kees Cook wrote: > > 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 >> does not say anything about the object it points to, >> So, __builtin_object_size can not directly us

Re: [C PATCH]: Add Walloc-type to warn about insufficient size in allocations

> 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, Just wondering if it'd be a good idea perhaps to warn if allo

Re: [PATCH] gcc-13/changes.html: Add and fix URL to -fstrict-flex-array option.

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-flex-array > is

Re: [PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

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 > > > > *htdocs/gcc-14/changes.html (Ca

Re: [PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

> 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

[PATCH] Add documentation for -Wflex-array-member-not-at-end.

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

Re: One question on the source code of tree-object-size.cc

> 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 >> info on the whole object. */ >>

Re: One question on the source code of tree-object-size.cc

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: #define LENGTH 10 struct fix { size_t foo; int array[LENGTH]; }; … int main () { struct fix *p; p = alloc_buf_more (); expect(__builtin_object_

Re: One question on the source code of tree-object-size.cc

> 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: >> >> #define LENGTH 10 >> >> struct f

Re: One question on the source code of tree-object-size.cc

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

Re: One question on the source code of tree-object-size.cc

> On Aug 4, 2023, at 3:38 AM, Kees Cook wrote: > > On Thu, Aug 03, 2023 at 09:31:24PM +, Qing Zhao wrote: >> So, the basic question is: >> >> Given the following: >> >> struct fix { >> int others; >> int array[10]; >> } >> >> extern struct fix * alloc_buf (); >> >> int main () >> { >>

Re: [PATCH] Add documentation for -Wflex-array-member-not-at-end.

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

Re: One question on the source code of tree-object-size.cc

> 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: >> #define LENGTH 10 >> struct fix { >> siz

Re: One question on the source code of tree-object-size.cc

> 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, >>> We have this same issue, for e

Re: One question on the source code of tree-object-size.cc

> 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 out first is, currently, even for regular fixed size

Re: One question on the source code of tree-object-size.cc

> 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: > > 1. the minimum size of the whole object that q points to. You mean

[V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hi, 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: 1. change the name "element_count" to "counted_by"; 2. change the parameter for the attribute from a STRING to an Identifier; 3. Add logic and test

[V2][PATCH 1/3] Provide counted_by attribute to flexible array member field (PR108896)

'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

[V2][PATCH 2/3] Use the counted_by atribute info in builtin object size [PR108896]

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):

[V2][PATCH 3/3] Use the counted_by attribute information in bound sanitizer[PR108896]

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

[V2][PATCH] gcc-14/changes.html: Deprecate a GCC C extension on flexible array members.

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

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Aug 7, 2023, at 12:16 PM, 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 >> review comments for the 1st version, the major changes in this version >> are: > > Thanks for the update! >

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hi, Martin, Thanks for raising this issue. 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 think that it’s necessary to have more discussion on this old issue and resolve it. The first thing that I’d l

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> 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 think that it’s >> necessary to have

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> On Aug 8, 2023, at 10:54 AM, Martin Uecker wrote: > > > > I am sure this has been discussed before, but seeing that you > test for a specific formula, let me point out the following: > > There at least three different size expression which could > make sense. Consider > > short foo { int

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> 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 be the same as >> the non-FAM one. >> i.e,

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hi, Martin, > On Aug 10, 2023, at 11:18 AM, Martin Uecker wrote: > > Am Donnerstag, dem 10.08.2023 um 10:58 -0400 schrieb Siddhesh Poyarekar: >> On 2023-08-10 10:47, Martin Uecker wrote: >>> Am Donnerstag, dem 10.08.2023 um 16:42 +0200 schrieb Jakub Jelinek: On Thu, Aug 10, 2023 at 04:38:21

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

> 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

Is this a bug for __builtin_dynamic_object_size?

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

Re: Is this a bug for __builtin_dynamic_object_size?

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 testing case: >> #include >

Another bug for __builtin_object_size? (Or expected behavior)

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;

Re: Another bug for __builtin_object_size? (Or expected behavior)

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

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

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

Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

Hi, Kees, Thanks for the testing case. Yes, I noticed this issue too, and already fixed it in my private branch. With the latest patch, the compilation has no issue: [opc@qinzhao-ol8u3-x86 108896]$ sh t /home/opc/Install/latest-d/bin/gcc -O2 -c -o /dev/null bug.c [opc@qinzhao-ol8u3-x86 108896]$

Re: Another bug for __builtin_object_size? (Or expected behavior)

> 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 fixed { >> size_t foo; >> char b; >> char

Re: Another bug for __builtin_object_size? (Or expected behavior)

> 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. >> Do you mean that after a subobje

Re: Another bug for __builtin_object_size? (Or expected behavior)

> 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. I'm not >>> sure if that's the case for maximum

Re: Another bug for __builtin_object_size? (Or expected behavior)

> 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 UNKNOWN? >>> >>> We can't be sure about

Re: Another bug for __builtin_object_size? (Or expected behavior)

> 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 >>> passes, but I agree it "rhymes". T

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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”: >> >&

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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

Re: [PATCH zero-call-used-regs] Add leafy mode for zero-call-used-regs

Hi, Alexandre, > On Jun 16, 2023, at 3:26 AM, Alexandre Oliva wrote: > > Hello, Qing, > > On Oct 27, 2022, Qing Zhao wrote: > > >> On Oct 26, 2022, at 5:29 PM, Alexandre Oliva wrote: >>> I'm sure there are other scenarios i

Re: [V1][PATCH 1/3] Provide element_count attribute to flexible array member field (PR108896)

> 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

[V10][PATCH 0/3] Accept and Handle the case when a structure including a FAM nested in another structure

This is the 10th version of the patch, which rebased on the latest trunk. This is an important patch needed by Linux Kernel security project. compared to the 9th patch, the ONLY change is: I split the 1st patch into the following two patches: patch 1/3: Introduce IR bit TYPE_INCLUDES_FLEXARRAY

  1   2   3   4   5   6   7   8   >