[gcc r15-947] Use the .ACCESS_WITH_SIZE in bound sanitizer.

2024-05-31 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:3d94fee616d6132075f3292a6eafdcb7b1d3f5a5 commit r15-947-g3d94fee616d6132075f3292a6eafdcb7b1d3f5a5 Author: Qing Zhao Date: Tue May 28 18:37:14 2024 + Use the .ACCESS_WITH_SIZE in bound sanitizer. gcc/c-family/ChangeLog: * c-ubsan.cc

[gcc r15-948] Add the 6th argument to .ACCESS_WITH_SIZE

2024-05-31 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:4c5bea7def13613fba166edb23289bab446b0b48 commit r15-948-g4c5bea7def13613fba166edb23289bab446b0b48 Author: Qing Zhao Date: Tue May 28 18:39:31 2024 + Add the 6th argument to .ACCESS_WITH_SIZE to carry the TYPE of the flexible array. Such

[gcc r15-946] Use the .ACCESS_WITH_SIZE in builtin object size.

2024-05-31 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:6f17933548fc34ee269e90546a590df8269cee60 commit r15-946-g6f17933548fc34ee269e90546a590df8269cee60 Author: Qing Zhao Date: Tue May 28 18:36:00 2024 + Use the .ACCESS_WITH_SIZE in builtin object size. gcc/ChangeLog: * tree-object-size.cc

[gcc r15-945] Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE.

2024-05-31 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:bb49b6e4f55891d0d8b596845118f40df6ae72a5 commit r15-945-gbb49b6e4f55891d0d8b596845118f40df6ae72a5 Author: Qing Zhao Date: Tue May 28 18:34:09 2024 + Convert references with "counted_by" attributes to/from .ACCESS_WITH_SIZE. Including the following

[gcc r15-944] Provide counted_by attribute to flexible array member field

2024-05-31 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:f824acd0e807546a733c122ab6340f18cef88766 commit r15-944-gf824acd0e807546a733c122ab6340f18cef88766 Author: Qing Zhao Date: Tue May 28 18:30:05 2024 + Provide counted_by attribute to flexible array member field 'counted_by (COUNT)' The

[gcc r15-211] Update the C FE routine "add_flexible_array_elts_to_size" C++ FE routine "layout_var_decl" to handle

2024-05-06 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:6634a409124a884ff66b3756568a7daae7d3c295 commit r15-211-g6634a409124a884ff66b3756568a7daae7d3c295 Author: Qing Zhao Date: Mon May 6 16:28:01 2024 + Update the C FE routine "add_flexible_array_elts_to_size" C++ FE routine "layout_var_decl" to handle the cases

[gcc r15-210] Add testing cases for flexible array members in unions and alone in structures.

2024-05-06 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:93f6a47583f3fa8a1b66856ecb19ec28f26b2ba4 commit r15-210-g93f6a47583f3fa8a1b66856ecb19ec28f26b2ba4 Author: Qing Zhao Date: Mon May 6 16:27:09 2024 + Add testing cases for flexible array members in unions and alone in structures. PR c/53548

[gcc r15-209] C and C++ FE changes to support flexible array members in unions and alone in structures. Adjust tes

2024-05-06 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:f27fc59d9f7c735d200fda647a487850144b10eb commit r15-209-gf27fc59d9f7c735d200fda647a487850144b10eb Author: Qing Zhao Date: Mon May 6 16:26:19 2024 + C and C++ FE changes to support flexible array members in unions and alone in structures. Adjust testcases for

[gcc r15-208] Allow flexible array members in unions and alone in structures [PR53548]

2024-05-06 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:adb1c8a0f167c3a1f7593d75f5a10eb07a5d741a commit r15-208-gadb1c8a0f167c3a1f7593d75f5a10eb07a5d741a Author: Qing Zhao Date: Mon May 6 16:25:04 2024 + Allow flexible array members in unions and alone in structures [PR53548] The request for GCC to accept

[gcc r11-11306] Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]

2024-04-02 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:4de35949e462d89926a171cd1ef7b6f40a308dab commit r11-11306-g4de35949e462d89926a171cd1ef7b6f40a308dab Author: Qing Zhao Date: Mon Mar 25 14:17:56 2024 + Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407] This is a

[gcc r12-10306] Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]

2024-04-02 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:5f23f9f141c4b52e8f4a9aadc88b8155cf1959a3 commit r12-10306-g5f23f9f141c4b52e8f4a9aadc88b8155cf1959a3 Author: Qing Zhao Date: Thu Feb 29 15:07:49 2024 + Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407] This is a

[gcc r13-8556] Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]

2024-04-02 Thread Qing Zhao via Gcc-cvs
https://gcc.gnu.org/g:2d9a9488e26233eb9497722fa9ccb88258f7402c commit r13-8556-g2d9a9488e26233eb9497722fa9ccb88258f7402c Author: Qing Zhao Date: Thu Feb 29 15:07:49 2024 + Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407] This is a bug

Re: Question on -fwrapv and -fwrapv-pointer

2023-09-15 Thread Qing Zhao via Gcc-patches
> 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

2023-09-15 Thread Qing Zhao via Gcc-patches
> 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

2023-09-15 Thread Qing Zhao via Gcc-patches
> 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

2023-09-15 Thread Qing Zhao via Gcc-patches
> 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

2023-09-15 Thread Qing Zhao via Gcc-patches
> 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

2023-09-15 Thread Qing Zhao via Gcc-patches
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

2023-09-14 Thread Qing Zhao via Gcc-patches
> 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

2023-09-14 Thread Qing Zhao via Gcc-patches
> 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

2023-09-14 Thread Qing Zhao via Gcc-patches
> 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

2023-09-14 Thread Qing Zhao via Gcc-patches
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

2023-09-14 Thread Qing Zhao via Gcc-patches
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

2023-09-14 Thread Qing Zhao via Gcc-patches
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]

2023-09-08 Thread Qing Zhao via Gcc-patches
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]

2023-09-08 Thread Qing Zhao via Gcc-patches
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)

2023-09-08 Thread Qing Zhao via Gcc-patches
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)

2023-09-08 Thread Qing Zhao via Gcc-patches
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

2023-09-01 Thread Qing Zhao via Gcc-patches
> 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]

2023-08-25 Thread Qing Zhao via Gcc-patches
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]

2023-08-25 Thread Qing Zhao via Gcc-patches
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)

2023-08-25 Thread Qing Zhao via Gcc-patches
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)

2023-08-25 Thread Qing Zhao via Gcc-patches
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)

2023-08-23 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-18 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-17 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-17 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-17 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-17 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-17 Thread Qing Zhao via Gcc-patches
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)

2023-08-16 Thread Qing Zhao via Gcc-patches
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)

2023-08-16 Thread Qing Zhao via Gcc-patches
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)

2023-08-16 Thread Qing Zhao via Gcc-patches
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?

2023-08-15 Thread Qing Zhao via Gcc-patches
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?

2023-08-14 Thread Qing Zhao via Gcc-patches
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: Should GCC warn about sizeof(flexible_struct)?

2023-08-14 Thread Qing Zhao via Gcc
> On Aug 14, 2023, at 2:41 AM, Richard Biener via Gcc wrote: > > On Fri, Aug 11, 2023 at 8:30 PM Alejandro Colomar via Gcc > wrote: >> >> Hi! >> >> Structures with flexible array members have restrictions about being >> used in arrays or within other structures, as the size of the enclosing

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

2023-08-10 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-10 Thread Qing Zhao via Gcc-patches
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)

2023-08-10 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-09 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-09 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-09 Thread Qing Zhao via Gcc-patches
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)

2023-08-07 Thread Qing Zhao via Gcc-patches
> 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.

2023-08-07 Thread Qing Zhao via Gcc-patches
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]

2023-08-04 Thread Qing Zhao via Gcc-patches
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]

2023-08-04 Thread Qing Zhao via Gcc-patches
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)

2023-08-04 Thread Qing Zhao via Gcc-patches
'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)

2023-08-04 Thread Qing Zhao via Gcc-patches
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

2023-08-04 Thread Qing Zhao via Gcc-patches
> 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

2023-08-04 Thread Qing Zhao via Gcc-patches
> 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

2023-08-04 Thread Qing Zhao via Gcc-patches
> 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

2023-08-04 Thread Qing Zhao via Gcc-patches
> 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.

2023-08-04 Thread Qing Zhao via Gcc-patches
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

2023-08-04 Thread Qing Zhao via Gcc-patches
> 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

2023-08-03 Thread Qing Zhao via Gcc-patches
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

2023-08-03 Thread Qing Zhao via Gcc-patches
> 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

2023-08-03 Thread Qing Zhao via Gcc-patches
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

2023-08-03 Thread Qing Zhao via Gcc-patches
> 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.

2023-08-03 Thread Qing Zhao via Gcc-patches
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.

2023-08-03 Thread Qing Zhao via Gcc-patches
> 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.

2023-08-02 Thread Qing Zhao via Gcc-patches
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.

2023-08-02 Thread Qing Zhao via Gcc-patches
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

2023-08-02 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-02 Thread Qing Zhao via Gcc-patches
> 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)

2023-08-02 Thread Qing Zhao via Gcc-patches
> 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

2023-08-02 Thread Qing Zhao via Gcc-patches
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

2023-08-01 Thread Qing Zhao via Gcc-patches
> 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)

2023-07-31 Thread Qing Zhao via Gcc-patches
, -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

2023-07-31 Thread Qing Zhao via Gcc-patches
> 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

2023-07-31 Thread Qing Zhao via Gcc-patches
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

2023-07-31 Thread Qing Zhao via Gcc-patches
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

2023-07-21 Thread Qing Zhao via Gcc-patches
> 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.

2023-07-21 Thread Qing Zhao via Gcc-patches
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)

2023-07-19 Thread Qing Zhao via Gcc-patches
>> >> 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)

2023-07-19 Thread Qing Zhao via Gcc-patches
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)

2023-07-18 Thread Qing Zhao via Gcc-patches
> 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)

2023-07-18 Thread Qing Zhao via Gcc-patches
> 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)

2023-07-18 Thread Qing Zhao via Gcc-patches
> 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)

2023-07-17 Thread Qing Zhao via Gcc-patches
> 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;

Questions on parallel processing and multi-threading support in GCC's profiling collection

2023-07-17 Thread Qing Zhao via Gcc
Hi, Jan, I did a little search online and also into GCC’s documentation, and found the following several options to support parallel processing and multi-threading during profiling collection: https://gcc.gnu.org/onlinedocs/gcc-10.5.0/gcc/Instrumentation-Options.html -fprofile-dir=path and

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

2023-07-10 Thread Qing Zhao via Gcc-patches
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)

2023-07-07 Thread Qing Zhao via Gcc-patches
=== 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)

2023-07-07 Thread Qing Zhao via Gcc-patches
> 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)

2023-07-06 Thread Qing Zhao via Gcc-patches
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

2023-06-29 Thread Qing Zhao via Gcc-patches
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

2023-06-28 Thread Qing Zhao via Gcc-patches
> 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

2023-06-27 Thread Qing Zhao via Gcc-patches
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)

2023-06-27 Thread Qing Zhao via Gcc-patches
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

2023-06-26 Thread Qing Zhao via Gcc-patches
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

2023-06-26 Thread Qing Zhao via Gcc-patches
> 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

  1   2   3   4   5   6   7   8   >