Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 12:53 PM, Xi Ruoyao wrote: > > On Fri, 2023-09-15 at 15:37 +, Qing Zhao wrote: >> >> >>> On Sep 15, 2023, at 11:29 AM, Richard Biener >>> wrote: >>> >>> >>> Am 15.09.2023 um 17:25 schrieb Qing Zhao :  > On Sep 15, 2023, at 8:41 AM,

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 1:26 PM, Richard Biener > wrote: > > > >> Am 15.09.2023 um 17:37 schrieb Qing Zhao : >> >>  >> On Sep 15, 2023, at 11:29 AM, Richard Biener wrote: > Am 15.09.2023 um 17:25 schrieb Qing Zhao :  > On Sep 15,

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 11:29 AM, Richard Biener > wrote: > > > >> Am 15.09.2023 um 17:25 schrieb Qing Zhao : >> >>  >> >>> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: >>> >>> >>> Qing Zhao writes: >>> Even though unsigned integer overflow is well defined, it might be

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 8:41 AM, Arsen Arsenović wrote: > > > Qing Zhao writes: > >> Even though unsigned integer overflow is well defined, it might be >> unintentional, shall we warn user about this? > > This would be better addressed by providing operators or functions that > do overflow

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote: > > On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote: CLANG already provided -fsanitize=unsigned-integer-overflow. GCC might need to do the same. >>> >>> NO. There is no such thing as unsigned integer overflow. That option >>> is

Re: [PATCH] tree optimization/111407--SSA corruption due to widening_mul opt

thanks. Committed as https://gcc.gnu.org/pipermail/gcc-cvs/2023-September/389614.html Qing > On Sep 15, 2023, at 2:12 AM, Richard Biener > wrote: > > On Thu, Sep 14, 2023 at 3:25 PM Qing Zhao via Gcc-patches > wrote: >> >> on conflict across an abnormal edge >&

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 14, 2023, at 4:57 PM, Andrew Pinski wrote: > > On Thu, Sep 14, 2023 at 1:50 PM Qing Zhao via Gcc-patches > wrote: >> >> >> >>> On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote: >>> >>> On Thu, 2023-09-14 at 15:57 +, Qin

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote: > > On Thu, 2023-09-14 at 15:57 +0000, Qing Zhao via Gcc-patches wrote: >> Currently, GCC behaves as following: >> >> /* True if overflow wraps around for the given integral or pointer type. >> That &

Re: Question on -fwrapv and -fwrapv-pointer

> On Sep 14, 2023, at 11:12 AM, Richard Biener > wrote: > > > >> Am 14.09.2023 um 17:01 schrieb Qing Zhao : >> >> Thanks for the info. >> >>> On Sep 14, 2023, at 10:06 AM, Richard Biener >>> wrote: >>> >>

Re: Question on -fwrapv and -fwrapv-pointer

Thanks for the info. > On Sep 14, 2023, at 10:06 AM, Richard Biener > wrote: > > On Thu, Sep 14, 2023 at 3:42 PM Qing Zhao via Gcc-patches > wrote: >> >> Hi, >> >> I have several questions on these options: >> >> 1.are pointer

Question on -fwrapv and -fwrapv-pointer

Hi, I have several questions on these options: 1.are pointers treated as signed integers in general? (I thought that pointers are addresses to the memory, should be treated as unsigned integer…) 2. If Yes, why? 3. why a separate option for pointesr -fwrapv-pointer in addition to -fwrapv if

[PATCH] tree optimization/111407--SSA corruption due to widening_mul opt

on conflict across an abnormal edge This is a bug in tree-ssa-math-opts.cc, when applying the widening mul optimization, the compiler needs to check whether the operand is in a ABNORMAL PHI, if YES, we should avoid the transformation. bootstrapped and regression tested on both aarch64 and x86,

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

Ping. thanks. Qing > On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote: > > Use the counted_by atribute info in builtin object size to compute the > subobject size for flexible array members. > > gcc/ChangeLog: > > PR C/108896 > * tree-object-size.cc (addr_object_size): Use the

Re: [V3][PATCH 3/3] Use the counted_by attribute information in bound sanitizer[PR108896]

Ping. thanks. Qing > On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote: > > Use the counted_by attribute information in bound sanitizer. > > gcc/c-family/ChangeLog: > > PR C/108896 > * c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute > information. > >

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

PIng. thanks. Qing > On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote: > > Provide a new counted_by attribute to flexible array member field. > > 'counted_by (COUNT)' > The 'counted_by' attribute may be attached to the flexible array > member of a structure. It indicates that the

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

Ping. Thanks. Qing > On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote: > > This is the 3rd version of the patch, per our discussion based on the > review comments for the 1st and 2nd version, the major changes in this > version are: > > ***Against 1st version: > 1. change the name

Re: RFC: Introduce -fhardened to enable security-related flags

> On Aug 29, 2023, at 3:42 PM, Marek Polacek via Gcc-patches > wrote: > > Improving the security of software has been a major trend in the recent > years. Fortunately, GCC offers a wide variety of flags that enable extra > hardening. These flags aren't enabled by default, though. And since

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

Use the counted_by attribute information in bound sanitizer. gcc/c-family/ChangeLog: PR C/108896 * c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute information. gcc/testsuite/ChangeLog: PR C/108896 *

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

Use the counted_by atribute info in builtin object size to compute the subobject size for flexible array members. 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):

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

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: ***Against 1st version: 1. change the name "element_count" to "counted_by"; 2. change the parameter for the attribute from a STRING to an

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

Provide a new counted_by attribute to flexible array member field. '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

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

> On Aug 18, 2023, at 12:00 PM, Qing Zhao via Gcc-patches > wrote: > > > >> 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 abou

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

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

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

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

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

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

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

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 =

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

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 = printf("the__bdos of p->array whole max is

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

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

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

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

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

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!

[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

[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. *

[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

[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

[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

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

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

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

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

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 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: One question on the source code of tree-object-size.cc

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

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

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. */ >>

[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

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

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

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

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

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

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

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

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

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,

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”

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 =

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

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

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

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)

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

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

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

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

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

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

=== Qing > On Jul 7, 2023, at 11:47 AM, Qing Zhao via Gcc-patches > wrote: > > > >> 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, >>> >>>

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

> 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. changed the argument from a string to an identifier >>

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

Hi, Kees, I have updated my V1 patch with the following changes: A. changed the name to "counted_by" B. changed the argument from a string to an identifier C. updated the documentation and testing cases accordingly. And then used this new gcc to test

Re: [PATCH] Introduce hardbool attribute for C

Hi, ALexandre, Thank you for the explanation. I am now clear with the interaction between hardbool and -ftrivial-auto-var-init, and also agree that clarifying the documentation on their interaction is good enough. Qing > On Jun 29, 2023, at 6:30 AM, Alexandre Oliva wrote: > > On Jun 28,

Re: [PATCH] Introduce hardbool attribute for C

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

Re: [PATCH v3] Introduce strub: machine-independent stack scrubbing

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

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

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:

Re: [PATCH] Introduce hardbool attribute for C

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,

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

> 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

Re: [PATCH] Introduce hardbool attribute for C

> 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 runtime? > > I have written such

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

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’s the LEAFY mode, >> The purpose of

Re: [PATCH] Introduce hardbool attribute for C

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

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

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

[V10][PATCH 1/3] Introduce IR bit TYPE_INCLUDES_FLEXARRAY for the GCC extension [PR77650]

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

[V10][PATCH 3/3] Use TYPE_INCLUDES_FLEXARRAY in __builtin_object_size [PR101832]

__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

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

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

[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

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

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

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

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

  1   2   3   4   5   6   7   8   >