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
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
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
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
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
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
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
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
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
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
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
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
> 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,
> 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,
> 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
> 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
> 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
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.cc (addr_object_size): Use the
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.
>
>
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
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
> 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):
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
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
>>> passes, but I agree it "rhymes".
> 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
> 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
> 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
> 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
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
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 testing case:
>> #include
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 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
> 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
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
> 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.
>>
> 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
> 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
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
> 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!
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
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
> 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
> 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
> 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
> 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 {
>>
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 +, 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 ()
>> {
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:
>>
>> #define LENGTH 10
>>
>> struct
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 ();
> 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. */
>>
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
>
>
>
> *htdocs/gcc-14/changes.html
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
> 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
> 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
> 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
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
> 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
, -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
> 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,
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”
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 =
> 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
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.
>>
>> 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
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
> 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
> 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,
> 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
> 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;
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
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.
---
===
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,
>>>
>>>
> 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
>>
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
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,
> 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.
>>>
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
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:
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,
> 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 - 100 of 799 matches
Mail list logo