> On Aug 1, 2023, at 6:45 PM, Kees Cook wrote:
>
> On Mon, Jul 31, 2023 at 08:14:42PM +0000, 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_o
> 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,
&
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-
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
>
>
> 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
When adding the option -Wflex-array-member-not-at-end in the commit
https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html
the documentation for this new option was missing.
This patch is to add the documentation for this warning option.
bootstrapped and also checked the documentation, no i
> 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
&g
:
>
> 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-obje
> 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:
>>
&
t that has
TYPE struct fix?
If the answer is YES, then the current__builtin_object_size algorithm can be
improved to determine __builtin_object_size(p->array, 0) with the TYPE of the
struct fix.
Qing
> On Aug 3, 2023, at 1:34 PM, Qing Zhao via Gcc-patches
> wrote:
>
> One
> 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];
>> }
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 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:
>>
> 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,
> 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 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:
>>>>>
>&
description of 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 t
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the flexible array
member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
same structure as the flexible array member. GCC uses this
inf
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the counted_by
attribute info.
* tree.cc (component_ref_has_counted_by_p): New function.
(component_ref_get_counted_by): New function.
* tree.h (component_ref_has_counted_by_p):
gcc/c-family/ChangeLog:
PR C/108896
* c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute
information.
gcc/testsuite/ChangeLog:
PR C/108896
* gcc.dg/ubsan/flex-array-counted-by-bounds.c: New test.
* gcc.dg/ubsan/flex-array-counted-by-bou
Hi,
This is the 2nd version of the patch.
Comparing to the 1st version, the only change is to address Richard's
comment on refering a warning option for diagnosing deprecated behavior.
Okay for committing?
thanks.
Qing
==
*htdocs/gcc-14/changes.html (Caveats): Add notice about deprecatin
> 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:
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 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
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 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
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 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
Hi, Sid,
For the following testing case:
#include
#define noinline __attribute__((__noinline__))
static void noinline alloc_buf_more (int index)
{
struct annotated {
long foo;
char b;
char array[index];
long c;
} q, *p;
p = &q;
printf("the__bdos of p->array whole max
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
Jakub and Sid,
During my study, I found an interesting behavior for the following small
testing case:
#include
#include
struct fixed {
size_t foo;
char b;
char array[10];
} q = {};
#define noinline __attribute__((__noinline__))
static void noinline bar ()
{
struct fixed *p = &q;
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
Hi,
After some more studying and consideration, the following is my thoughts:
For a structure with FMA annotated with counted_by attribute: (the following
small example)
struct annotated {
size_t foo;
char b;
char array[] __attribute__((counted_by (foo)));
};
#def
]$
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
> 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
> 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 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.
> 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 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
&g
> 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”:
>>
>&
> On Jun 16, 2023, at 3:21 AM, Martin Uecker wrote:
>
> Am Donnerstag, dem 15.06.2023 um 16:55 + schrieb Joseph Myers:
>> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>>
> ...
>>> 1. Update the routine “c_parser_postfix_expression” (is this the
Hi, Alexandre,
> On Jun 16, 2023, at 3:26 AM, Alexandre Oliva wrote:
>
> Hello, Qing,
>
> On Oct 27, 2022, Qing Zhao wrote:
> <https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604480.html>
>
>> On Oct 26, 2022, at 5:29 PM, Alexandre Oliva wrote:
>&
> On Jun 16, 2023, at 1:07 PM, Martin Uecker wrote:
>
> Am Freitag, dem 16.06.2023 um 16:21 + schrieb Joseph Myers:
>> On Fri, 16 Jun 2023, Martin Uecker via Gcc-patches wrote:
>>
Note that no expressions can start with the '.' token at present. As soon
as you invent a new kin
have been
approved already.
for the patch 3/3, I will wait for several days, if there is no
objection or new comments, I will commit it the end of this week.
Please let me know if you have comments and suggestions.
thanks.
Qing
Qing Zhao (3):
Introduce IR bit TYPE_INCLUDES_FLEXARRAY for the
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
__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 tree-o
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 TYPE_INCLUDES_FLEXARR
> 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 during p
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 (build_qualified
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
> 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 runt
> 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
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, bu
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,
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 th
> 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.
>>>
On Jun 28, 2023, Qing Zhao wrote:
>
>> In summary, Ada’s Boolean variables (whether it’s hardened or not) are
>> represented as
>> enumeration types in GNU IR.
>
> Not quite. Only boolean types with representation clauses are. Those
> without (such as Standard.Boolean
n on this?
thanks.
Qing
> On May 26, 2023, at 4:40 PM, Kees Cook wrote:
>
> On Thu, May 25, 2023 at 04:14:47PM +, Qing Zhao wrote:
>> GCC will pass the number of elements info from the attached attribute to
>> both
>> __builtin_dynamic_object_size and bound
> 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. ch
ser errors during compilation time, or the sanitizer
option '-fsanitize=counted-by-attribute' to detect such user errors
during runtime.
=====
Qing
> On Jul 7, 2023, at 11:47 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Jul 6, 2023, at 5:10
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.
---
htdocs/gcc-14/ch
Thank you for fixing this issue.
Qing
> On Feb 15, 2023, at 2:19 PM, Hans-Peter Nilsson wrote:
>
> Tested for cris-elf. Ok to commit?
>
> -- >8 --
> Looks like there's a failed assumption that
> sizeof (union U { char u1[5]; int u2; float u3; }) == 8.
> However, for "packed" targets like cris
Ping…
Qing
> On Feb 10, 2023, at 7:50 PM, Qing Zhao wrote:
>
> These are the 3rd version of the patches for PR101832, to fix
> builtin_object_size to correctly handle component_ref to a
> structure/union field that includes a flexible array member.
>
> also includes a doc
Ping…
Qing
> On Feb 10, 2023, at 7:50 PM, Qing Zhao wrote:
>
> GCC extension accepts the case when a struct with a C99 flexible array member
> is embedded into another struct or union (possibly recursively).
> __builtin_object_size should treat such struct as flexible s
Ping…
Qing
> On Feb 10, 2023, at 7:50 PM, Qing Zhao wrote:
>
> on structure with C99 flexible array member being nested in another structure.
>
> This is also fixed PR77650.
>
> " GCC extension accepts a structure containing a ISO C99 "flexible array
> mem
This is a bug in tree-ssa-uninit.cc.
When doing the following:
/* Ignore the call to .DEFERRED_INIT that define the original
var itself as the following case:
temp = .DEFERRED_INIT (4, 2, “alt_reloc");
alt_reloc = temp;
In order to avoid generating warning for the fake us
> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote:
>
> On Fri, Feb 17, 2023 at 10:26:03PM +0000, Qing Zhao via Gcc-patches wrote:
>> + else if (!DECL_NAME (lhs_var))
>> +{
>> + char *lhs_var_name_str
>> += xas
> On Feb 20, 2023, at 10:17 AM, Jakub Jelinek wrote:
>
> On Mon, Feb 20, 2023 at 03:04:51PM +0000, Qing Zhao via Gcc-patches wrote:
>>
>>
>>> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek wrote:
>>>
>>> On Fri, Feb 17, 2023 at 1
This is the 2nd version of the patch.
compared to the first version, the major change is:
use sprintf to replace xasprintf per Jacub's suggestion.
bootstrapped and regression tested on both x86 and aarch64.
Okay for committing?
thanks.
Qing
===
This is a bug in tree-ssa-
Ping * 2.
Hi, Joseph and Richard,
Could you please review this patch and let me know whether it’s ready for
committing into GCC13?
This is an important bug that need to be fixed for kernel security purpose.
thanks.
Qing
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle.com
Ping * 2.
Hi, Joseph and Richard,
Could you please review this patch and let me know whether it’s ready for
committing into GCC13?
thanks.
Qing
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle.com>>
Subject: [v3][PATCH 2/2] Update documentation to clarify a GCC ext
> On Feb 23, 2023, at 4:24 PM, Joseph Myers wrote:
>
> On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> +@item
>> +The structure with a C99 flexible array member is the field of
>> +another union, for example:
>> +
>> +@smallexample
&g
> On Feb 23, 2023, at 5:04 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Feb 23, 2023, at 4:24 PM, Joseph Myers wrote:
>>
>> On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:
>>
>>> +@item
>>> +The structure with a C99
> On Feb 23, 2023, at 7:56 PM, Joseph Myers wrote:
>
> On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> But the following:
>>
>> struct flex1 { int length1; char data1[]; };
>> struct flex2 { int length2; char data2[]; };
>> union uni
middle of
another structure.
5. add a new warning option -Wgnu-variable-sized-type-not-at-end for
identifing all such cases.
bootstrapped and regression tested on aarch64 and x86.
Okay for commit?
thanks.
Qing
Qing Zhao (2):
Handle component_ref to a structre/union field including C99 FAM
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-decl.cc (finish_struct):
on a structure with a C99 flexible array member being nested in
another structure.
"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:
* The st
Ping.
Qing
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle.com>>
Subject: [V2][PATCH] Fixing PR107411
Date: February 21, 2023 at 9:46:04 AM EST
To: ja...@redhat.com<mailto:ja...@redhat.com>,
rguent...@suse.de<mailto:rguent...@suse.de>
Cc: gcc-patches@gcc.
Hi, Jakub,
Thanks a lot for fixing this issue.
I have several questions in below:
> On Feb 28, 2023, at 3:26 AM, Jakub Jelinek via Gcc-patches
> wrote:
> I think -fstrict-flex-arrays* options can be considered as language
> mode changing options, by default flexible member-like arrays are
> ha
> On Feb 28, 2023, at 12:49 PM, Jakub Jelinek wrote:
>
> On Tue, Feb 28, 2023 at 04:13:28PM +0000, Qing Zhao wrote:
>>> On Feb 28, 2023, at 3:26 AM, Jakub Jelinek via Gcc-patches
>>> wrote:
>>> I think -fstrict-flex-arrays* options can be considered as la
> On Feb 28, 2023, at 4:59 PM, Jakub Jelinek wrote:
>
> On Tue, Feb 28, 2023 at 07:19:40PM +0000, Qing Zhao wrote:
>> Understood.
>> So, your patch fixed this bug, and then [0] arrays are instrumented by
>> default with this patch.
>>
>>> Well, it
Ping
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> Hi, Joseph and Richard,
>
> Could you please review this patch and let me know whether it’s ready
> for committing into GCC13?
>
> The fix to Bug PR101832 is an important patch for kernel security
> pur
Ping.
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> GCC extension accepts the case when a struct with a C99 flexible array member
> is embedded into another struct or union (possibly recursively).
> __builtin_object_size should treat such struct as flexible s
Ping.
Qing
> On Feb 24, 2023, at 1:35 PM, Qing Zhao wrote:
>
> on a structure with a C99 flexible array member being nested in
> another structure.
>
> "GCC extension accepts a structure containing an ISO C99 "flexible array
> member", or a union c
Hi, Jan,
I am studying one profiling feedback ICE bug with GCC8 recently.
It’s an assertion failure inside the routine “compute_working_sets”of gcov-io.c:
gcov_nonruntime_assert (ws_ix == NUM_GCOV_WORKING_SETS);
After some debugging and study, I found that the corresponding .gcda file has
two
Honza,
Thanks a lot for your information.
> On Mar 8, 2023, at 8:19 AM, Jan Hubicka wrote:
>
>> Hi, Jan,
>>
>> I am studying one profiling feedback ICE bug with GCC8 recently.
>> It’s an assertion failure inside the routine “compute_working_sets”of
>> gcov-io.c:
>>
>> gcov_nonruntime_asser
> On Mar 9, 2023, at 7:20 AM, Richard Biener wrote:
>
> On Fri, 24 Feb 2023, Qing Zhao wrote:
>
>> GCC extension accepts the case when a struct with a C99 flexible array member
>> is embedded into another struct or union (possibly recursively).
>> __builtin
> On Mar 10, 2023, at 2:54 AM, Richard Biener wrote:
>
> On Thu, 9 Mar 2023, Qing Zhao wrote:
>
>>
>>
>>> On Mar 9, 2023, at 7:20 AM, Richard Biener wrote:
>>>
>>> On Fri, 24 Feb 2023, Qing Zhao wrote:
>>>
>>>>
> On Mar 12, 2023, at 7:14 PM, Sandra Loosemore wrote:
>
> On 3/2/23 17:03, Qing Zhao via Gcc-patches wrote:
>> Ping.
>
> It looks to me like there is an associated code patch (for PR101832) that is
> still under technical discussion?
Yes, the 1st patch in thi
Hi, Richard,
Do you have more comments on my responds to your previous questions?
thanks.
Qing
> On Mar 10, 2023, at 8:48 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Mar 10, 2023, at 2:54 AM, Richard Biener wrote:
>>
>> On Thu, 9 Mar 2023, Qing
> On Mar 14, 2023, at 5:04 AM, Richard Biener wrote:
>
> On Mon, 13 Mar 2023, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> Do you have more comments on my responds to your previous questions?
>
> No, generally we're not good at naming the shared bit
we can completely delete this case from GCC support.
Right now, GCC’s implementation cannot handle such case consistently. So, how
to document this case is really hard.
> On Mar 14, 2023, at 11:26 PM, Sandra Loosemore
> wrote:
>
> On 2/24/23 11:35, Qing Zhao via Gcc-patches wrote:
Honza,
Thanks a lot for your comments.
> On May 9, 2023, at 6:22 AM, Jan Hubicka wrote:
>
>
> From my understanding, -fprofile-partial-training is one important option
> for PGO performance.
I don't think so, speed benefit would be rather small I guess.
>>> I saw some
> On May 10, 2023, at 9:15 AM, Jan Hubicka wrote:
>
>> Honza,
>>> Main motivation for this was profiling programs that contain specific
>>> code paths for different CPUs (such as graphics library in Firefox or Linux
>>> kernel). In the situation training machine differs from the machine
>>> pro
> On May 11, 2023, at 12:08 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On May 10, 2023, at 9:15 AM, Jan Hubicka wrote:
>>
>>> Honza,
>>>> Main motivation for this was profiling programs that contain specific
>>>> code path
Hi,
This is the 7th version of the patch, which rebased on the latest trunk.
This is an important patch needed by Linux Kernel security project.
We already have an extensive discussion on this issue and I have went
through 6 revisions of the patches based on the discussion and resolved
all the c
GCC extension accepts the case when a struct with a flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-decl.cc (finish_struct): Set
on a structure with a C99 flexible array member being nested in
another structure.
"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 stru
Joseph,
Thanks a lot for the review. And sorry for my late reply (just came back from a
short vacation).
> On May 19, 2023, at 5:12 PM, Joseph Myers wrote:
>
> On Fri, 19 May 2023, Qing Zhao via Gcc-patches wrote:
>
>> +GCC extension accepts a structure containing an ISO
Bernhard,
Thanks a lot for your comments.
> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer
> wrote:
>
> On Fri, 19 May 2023 20:49:47 +
> Qing Zhao via Gcc-patches wrote:
>
>> GCC extension accepts the case when a struct with a flexible array member
>
701 - 800 of 1427 matches
Mail list logo
