> On Oct 26, 2023, at 1:05 PM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>>
>>> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Bi
>>>>>>>
>>>>>>> Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar:
>>>>>>>>> On 2023-10-25 04:16, Martin Uecker wrote:
>>>>>>>>> Am Mittwoch, dem 25.10.2
Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
>>>>>>>>
>>>>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>>>>>
>>>>>>>>> Am Dienstag, dem 24.10.2023 um
> On Oct 26, 2023, at 4:56 AM, Richard Biener
> wrote:
>
> On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote:
>>
>> On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote:
>>> For the code generation impact:
>>>
>>> turning
> On Oct 26, 2023, at 1:21 AM, Jakub Jelinek wrote:
>
> On Wed, Oct 25, 2023 at 07:03:43PM +0000, Qing Zhao wrote:
>> For the code generation impact:
>>
>> turning the original x.buf
>> to a builtin function call
>> __builtin_with_access_and_size(x
> On Oct 25, 2023, at 6:06 PM, Kees Cook wrote:
>
> On Wed, Oct 25, 2023 at 01:27:29PM +0000, Qing Zhao wrote:
>> A. Add an additional argument, the size parameter, to __bdos,
>> A.1, during FE;
>> A.2, during gimplification phase;
>
> I just wanted
> On Oct 25, 2023, at 11:38 AM, Richard Biener
> wrote:
>
>
>
>> Am 25.10.2023 um 16:50 schrieb Siddhesh Poyarekar :
>>
>> On 2023-10-25 09:27, Qing Zhao wrote:
>>>>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar
>>>
> On Oct 25, 2023, at 10:50 AM, Siddhesh Poyarekar wrote:
>
> On 2023-10-25 09:27, Qing Zhao wrote:
>>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-10-24 18:51, Qing Zhao wrote:
>>>> Thanks for the proposal!
>
t;>>> Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
>>>>>
>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>>
>>>>>> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>>
iener:
>>>>
>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>
>>>>> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>>>>>> Hi, Sid,
>>>>>>
>>>>>> Real
> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-24 18:51, Qing Zhao wrote:
>> Thanks for the proposal!
>> So what you suggested is:
>> For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
>> then the call to th
> On Oct 24, 2023, at 4:38 PM, Martin Uecker wrote:
>
> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>> Hi, Sid,
>>
>> Really appreciate for your example and detailed explanation. Very helpful.
>> I think that this example is an excel
> On Oct 24, 2023, at 5:03 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-24 16:30, Qing Zhao wrote:
>> Situation 2: With O0, the routine “get_size_from” was NOT inlined into
>> “foo”, therefore, the call to __bdos is Not in the same routine as the
>> instantiation
Hi, Sid,
Really appreciate for your example and detailed explanation. Very helpful.
I think that this example is an excellent example to show (almost) all the
issues we need to consider.
I slightly modified this example to make it to be compilable and run-able, as
following:
(but I still
> On Oct 23, 2023, at 3:37 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 19:00 + schrieb Qing Zhao:
>>
>>> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote:
>>>
>>> Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
>
> On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-23 14:06, Martin Uecker wrote:
>> We should aim for a good integration with the BDOS pass, so
>> that it can propagate the information further, e.g. the
>> following should work:
>> struct { int L; char buf[]
> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
>> Am Montag, dem 23.10.2023 um 16:37 +0000 schrieb Qing Zhao:
>>>
>>>> On Oct 23, 2023, at 11:57 AM, Richard Biener
>>>>
> On Oct 23, 2023, at 2:06 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao:
>>
>>> On Oct 23, 2023, at 11:57 AM, Richard Biener
>>> wrote:
>>>
>>>
>>>
>>>> Am 23.10.2023 um 16:
> On Oct 20, 2023, at 3:54 PM, Martin Uecker wrote:
>
> Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao:
>>
>>> On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
>>>
>>> On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote:
>>
> On Oct 23, 2023, at 11:57 AM, Richard Biener
> wrote:
>
>
>
>> Am 23.10.2023 um 16:56 schrieb Qing Zhao :
>>
>>
>>
>>> On Oct 23, 2023, at 3:57 AM, Richard Biener
>>> wrote:
>>>
>>>> On Fri, Oct 20, 2023
> On Oct 23, 2023, at 8:34 AM, Richard Biener
> wrote:
>
> On Mon, Oct 23, 2023 at 1:27 PM Siddhesh Poyarekar
> wrote:
>>
>> On 2023-10-23 03:57, Richard Biener wrote:
>>> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
>>>>
>>
> On Oct 23, 2023, at 3:57 AM, Richard Biener
> wrote:
>
> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
>>
>>
>>
>>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-10-20 14:38, Qing Zhao wrote:
&
> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-20 14:38, Qing Zhao wrote:
>> How about the following:
>> Add one more parameter to __builtin_dynamic_object_size(), i.e
>> __builtin_dynamic_object_size (_1,1,array_annotated->foo)?
>
> On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
>
> On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote:
>> Am Donnerstag, dem 19.10.2023 um 16:33 -0700 schrieb Kees Cook:
>>> On Wed, Oct 18, 2023 at 09:11:43PM +, Qing Zhao wrote:
>>>> As I r
> On Oct 20, 2023, at 2:22 PM, Richard Biener
> wrote:
>
>
>
>> Am 20.10.2023 um 19:09 schrieb Qing Zhao :
>>
>> Sid,
>>
>> (Richard, can you please help me to make sure this? Thanks a lot)
>>
>> I studied a little bit more o
Sid,
(Richard, can you please help me to make sure this? Thanks a lot)
I studied a little bit more on the following question you raised during the
review process:
For the following small testing case:
1 struct annotated {
2 int foo;
3 char array[] __attribute__((counted_by (foo)));
g the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously
> in this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
>
>> Comparing
> On Oct 5, 2023, at 4:08 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-25 11:24, 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
Hi, Sid,
Thanks a lot for the detailed comments.
See my responds embedded below.
Qing
> On Oct 5, 2023, at 4:01 PM, Siddhesh Poyarekar wrote:
>
>
>
> On 2023-08-25 11:24, Qing Zhao wrote:
>> Use the counted_by atribute info in builtin object size to compute
Marek,
Sorry for the late comment (I was just back from a long vacation immediate
after Cauldron).
One question:
Is the option “-fhandened” for production build or for development build?
If it’s for development build, then adding -ftrivial-auto-var-init=pattern is
reasonable since the
> On Oct 6, 2023, at 4:01 PM, Martin Uecker wrote:
>
> Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar:
>> On 2023-10-06 01:11, Martin Uecker wrote:
>>> Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh
> On Oct 18, 2023, at 11:18 AM, Siddhesh Poyarekar wrote:
>
> On 2023-10-18 10:51, Qing Zhao wrote:
>>>>> + member FIELD_DECL is a valid field of the containing structure's
>>>>> fieldlist,
>>>>> + FIELDLIST, Report error and remov
>>> + member FIELD_DECL is a valid field of the containing structure's
>>> fieldlist,
>>> + FIELDLIST, Report error and remove this attribute when it's not. */
>>> +static void
>>> +verify_counted_by_attribute (tree fieldlist, tree field_decl)
>>> +{
>>> + tree attr_counted_by =
-25 11:24, Qing Zhao wrote:
>> Provide a new counted_by attribute to flexible array member field.
>
> The obligatory "I can't ack the patch but here's a review" disclaimer :)
>
>> 'counted_by (COUNT)'
>> The 'counted_by' attribute may be attached to th
?
>
> * * *
>
> Cross ref: The patch adding the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously
> in this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08.23 1
Hi,
I’d like to ping this patch set one more time.
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
Hi,
I’d like to ping this patch set one more time.
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
Hi,
I’d like to ping this patch set one more time.
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
Hi,
I’d like to ping this patch set one more time!
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:
> On Sep 17, 2023, at 12:36 PM, Hans-Peter Nilsson via Gcc-patches
> wrote:
>
>> From: Sam James
>> Date: Sun, 17 Sep 2023 05:00:37 +0100
>
>> Hans-Peter Nilsson via Gcc-patches writes:
>>
Date: Tue, 29 Aug 2023 15:42:27 -0400
From: Marek Polacek via Gcc-patches
>>>
> On Sep 15, 2023, at 12:53 PM, Xi Ruoyao wrote:
>
> On Fri, 2023-09-15 at 15:37 +0000, Qing Zhao wrote:
>>
>>
>>> On Sep 15, 2023, at 11:29 AM, Richard Biener
>>> wrote:
>>>
>>>
>>>
>>>> Am 15.09.2023 um
> 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:
>>>>
>>>>
>>
> 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
> 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 operator
> On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote:
>
> On Thu, 2023-09-14 at 21:41 +0000, Qing Zhao wrote:
>>>> CLANG already provided -fsanitize=unsigned-integer-overflow. GCC
>>>> might need to do the same.
>>>
>>> NO. There is no s
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
>&
> 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
> 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
&
> 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:
>>>
>>
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
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
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,
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
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
>
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 str
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:
> 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
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
*
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):
nu.org/pipermail/gcc-patches/2023-May/619708.html
and more discussions on
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626376.html
Okay for committing?
thanks.
Qing
Qing Zhao (3):
Provide counted_by attribute to flexible array member field (PR108896)
Use the counted_by atribute info in bu
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
> 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
> 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
>>
> On Aug 17, 2023, at 4:57 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 16:23, Qing Zhao wrote:
>>>> Then, I think whatever MIN or MAX, the early phase has more precise
>>>> information than the later phase, we should use its result if it’s NOT
>&g
> On Aug 17, 2023, at 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
> On Aug 17, 2023, at 1:49 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-17 09:58, Qing Zhao wrote:
>>> So this is a (sort of) known issue, which necessitated the early_objsz pass
>>> to get an estimate before a subobject reference was optimized to a MEM_REF
> On Aug 17, 2023, at 7:00 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-16 11:59, Qing Zhao wrote:
>> Jakub and Sid,
>> During my study, I found an interesting behavior for the following small
>> testing case:
>> #include
>> #include
>> struct fi
]$
Qing
> On Aug 17, 2023, at 2:38 AM, Kees Cook wrote:
>
> On Wed, Aug 16, 2023 at 10:31:30PM -0700, Kees Cook wrote:
>> On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote:
>>> This is the 2nd version of the patch, per our discussion based on the
>>> re
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)));
};
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
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 =
Thanks.
I just filed a PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030 to record
this issue and added you to the CC list.
Qing
> On Aug 15, 2023, at 6:57 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-14 19:12, Qing Zhao wrote:
>> Hi, Sid,
>> For the following test
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
> 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;> On Thu, Aug 10, 2023 at 04:38:21PM +0200, Martin Uecker wrote:
>>>>> Am Donnerstag, dem 10.08.2023 um 13:59 + schrieb Qing Zhao:
>>>>>>
>>>>>>> On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
>>>>>>>
>&g
> On Aug 10, 2023, at 2:58 AM, Martin Uecker wrote:
>
> Am Mittwoch, dem 09.08.2023 um 20:10 + schrieb Qing Zhao:
>>
>>> On Aug 9, 2023, at 12:21 PM, Michael Matz wrote:
>
> ...
>>
>> By definition, the sizeof() of a struct with FAM might not b
structure with FAM cannot be an element of an
array,
the tailing padding might not be necessary?
Qing
>
>
> Martin
>
>
>
> Am Montag, dem 07.08.2023 um 09:16 -0700 schrieb Kees Cook:
>> On Fri, Aug 04, 2023 at 07:44:28PM +, Qing Zhao wrote:
>>> This is the 2nd
> On Aug 9, 2023, at 12:21 PM, Michael Matz wrote:
>
> Hello,
>
> On Wed, 9 Aug 2023, Qing Zhao wrote:
>
>> Although this is an old FAM related issue that does not relate to my current
>> patch
>> (and might need to be resolved in a separate patch). I t
o { int a; short b; char t[3]; };
>
> This would make the most sense to me, but it has 12 bytes
> because the padding is according to the usual alignment
> rules.
>
>
> Martin
>
>
>
> Am Montag, dem 07.08.2023 um 09:16 -0700 schrieb Kees Cook:
>> On Fri, Aug
> On Aug 7, 2023, at 12:16 PM, Kees Cook wrote:
>
> On Fri, Aug 04, 2023 at 07:44:28PM +0000, Qing Zhao wrote:
>> This is the 2nd version of the patch, per our discussion based on the
>> review comments for the 1st version, the major changes in this version
>> are:
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
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/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
'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
work on:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619708.html
Okay for committing?
thanks.
Qing
Qing Zhao (3):
Provide counted_by attribute to flexible array member field (PR108896)
Use the counted_by atribute info in builtin object size [PR108896]
Use the counted_by attrib
> 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:
>>>>>
>>>>
> On Aug 4, 2023, at 12:36 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-04 11:27, Qing Zhao wrote:
>>> On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-08-03 13:34, Qing Zhao wrote:
>>>> One thing I need to point
> On Aug 4, 2023, at 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 struc
> 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:
>>
Thanks.
I just updated the doc per your suggestion and committed as:
https://gcc.gnu.org/pipermail/gcc-cvs/2023-August/387588.html
Qing
> On Aug 3, 2023, at 1:29 PM, Joseph Myers wrote:
>
> On Thu, 3 Aug 2023, Qing Zhao via Gcc-patches wrote:
>
>> +@opindex Wflex-array
> On Aug 4, 2023, at 3:38 AM, Kees Cook wrote:
>
> On Thu, Aug 03, 2023 at 09:31:24PM +0000, Qing Zhao wrote:
>> So, the basic question is:
>>
>> Given the following:
>>
>> struct fix {
>> int others;
>> int array[10];
>> }
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
> 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:
>>
&
ar wrote:
>
> On 2023-08-03 12:43, Qing Zhao wrote:
>>> Surely we could emit that for __bdos(q->array, 0) though, couldn't we?
>> For __bdos(q->array, 0), we only have the access info for the sub-object
>> q->array, we can surely decide the size of the sub-objec
> 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
>>
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
> 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
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
>
>
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 -fst
> 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
201 - 300 of 1199 matches
Mail list logo
