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

on a structure with a C99 flexible array member being nested in another structure. "The GCC extension accepts a structure containing an ISO C99 "flexible array member", or a union containing such a structure (possibly recursively) to be a member of a structure. There are two situations: * A

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

__builtin_object_size should treat struct with TYPE_INCLUDES_FLEXARRAY as flexible size. gcc/ChangeLog: PR tree-optimization/101832 * tree-object-size.cc (addr_object_size): Handle structure/union type when it has flexible size. gcc/testsuite/ChangeLog: PR tree-o

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

on a structure with a C99 flexible array member being nested in another structure GCC extension accepts the case when a struct with a flexible array member is embedded into another struct or union (possibly recursively) as the last field. This patch is to introduce the IR bit TYPE_INCLUDES_FLEXARR

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

> On Jun 16, 2023, at 5:35 PM, Joseph Myers wrote: > > On Fri, 16 Jun 2023, Qing Zhao via Gcc-patches wrote: > >>> So for >>> >>> struct foo { int c; int buf[(struct { int d; }){ .d = .c }]; }; >>> >>> one knows during p

Re: [PATCH] Introduce hardbool attribute for C

Hi, Alexandre, > > diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc > index 22e240a3c2a55..f9cc609b54d94 100644 > --- a/gcc/c/c-typeck.cc > +++ b/gcc/c/c-typeck.cc > @@ -2226,6 +2226,35 @@ convert_lvalue_to_rvalue (location_t loc, struct > c_expr exp, > exp.value = convert (build_qualified

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

Hi, Alexandre, > On Jun 21, 2023, at 9:16 PM, Alexandre Oliva wrote: > > Hello, Qing, > > On Jun 16, 2023, Qing Zhao wrote: > >> As I mentioned in the previous round of review, I think that the >> documentation >> might need to add more details on what’s the LEAFY mode, >> The purpose of it

Re: [PATCH] Introduce hardbool attribute for C

> On Jun 21, 2023, at 10:35 PM, Alexandre Oliva wrote: > > On Jun 21, 2023, Qing Zhao wrote: > >> I see that you have testing case to check the above built_in_trap call >> is generated by FE. >> Do you have a testing case to check the trap is happening at runtime? > > I have written such te

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

> On Jun 23, 2023, at 7:27 PM, Alexandre Oliva wrote: > > On Jun 23, 2023, Qing Zhao via Gcc-patches wrote: > >> It’s better to add this definition earlier in the list of the “three >> basic values”, to make it “four basic values”, like the following: > > Oh, m

Re: [PATCH] Introduce hardbool attribute for C

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

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

might need to extend the C FE to accept ".count” in the future. Let me know if you have further comments and suggestions. thanks. Qing > On Jun 20, 2023, at 3:40 PM, Qing Zhao via Gcc-patches > wrote: > > > >> On Jun 16, 2023, at 5:35 PM, Joseph Myers wrote:

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

Hi, Alexandre, Thanks a lot for the work. I think that this will be a valuable feature to be added for GCC’s security functionality. I have several questions on this patch: 1. The implementation of register scrubbing, -fzero-call-used-regs, is to insert the register zeroing sequence in th

Re: [PATCH] Introduce hardbool attribute for C

> On Jun 28, 2023, at 3:26 AM, Alexandre Oliva wrote: > > I'd probably have arranged for the front-end to create the initializer > value, because expansion time is too late to figure it out: we may not > even have the front-end at hand any more, in case of lto compilation. >>>

Re: [PATCH] Introduce hardbool attribute for C

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

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

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

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

> On Jul 6, 2023, at 5:10 PM, Martin Uecker wrote: > > Am Donnerstag, dem 06.07.2023 um 18:56 + schrieb Qing Zhao: >> Hi, Kees, >> >> I have updated my V1 patch with the following changes: >> A. changed the name to "counted_by" >> B. changed the argument from a string to an identifier >> C

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

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

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

Hi, This is the change for the GCC14 releaes Notes on the deprecating of a C extension about flexible array members. Okay for committing? thanks. Qing *htdocs/gcc-14/changes.html (Caveats): Add notice about deprecating a C extension about flexible array members. --- htdocs/gcc-14/ch

Re: [PATCH] testsuite: Handle "packed" targets in c-c++-common/auto-init-7.c and -8.c

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

Re: [v3][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

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 documentation update for

Re: [v3][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

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 size. > > gcc/c/ChangeLog

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

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 > member", or a union containing such a st

[PATCH] Fixing PR107411

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

Re: [PATCH] Fixing PR107411

> 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

Re: [PATCH] Fixing PR107411

> 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

[V2][PATCH] Fixing PR107411

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-

Fwd: [v3][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

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

Fwd: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

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 extension (PR7

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

> 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

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

> 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

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

> 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

[V4][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

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 purpose. it's better to be put into GCC13. = These are the 4th version of the

[v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

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

[V4][PATCH 2/2] Update documentation to clarify a GCC extension

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

Fwd: [V2][PATCH] Fixing PR107411

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, rguent...@suse.de Cc: gcc-patches@gcc.gnu.org

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

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

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

> On Feb 28, 2023, at 12:49 PM, Jakub Jelinek wrote: > > On Tue, Feb 28, 2023 at 04:13:28PM +, 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 language >>> mode changing options, by d

Re: [PATCH] ubsan: Honor -fstrict-flex-arrays= in -fsanitize=bounds [PR108894]

> On Feb 28, 2023, at 4:59 PM, Jakub Jelinek wrote: > > On Tue, Feb 28, 2023 at 07:19:40PM +, Qing Zhao wrote: >> Understood. >> So, your patch fixed this bug, and then [0] arrays are instrumented by >> default with this patch. >> >>> Well, it would complain about >>> struct S { int a;

Re: [V4][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

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 > purpose. it's better to be put i

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

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 size. > > gcc/c/ChangeLog

Re: [V4][PATCH 2/2] Update documentation to clarify a GCC extension

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 containing such a structure (possibly recursive

HELP: Questions on multiple PROGRAM_SUMMARY sections in a profiling data file

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

Re: HELP: Questions on multiple PROGRAM_SUMMARY sections in a profiling data file

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

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

> 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_object_size should treat such struct

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

> 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: >>> GCC extension accepts the case when a struct with a C99 flexible array m

Re: [V4][PATCH 2/2] Update documentation to clarify a GCC extension

> 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

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

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

Re: [v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

nd Jakub should be the ones to approve these patches? I will update the patches with your suggestions for the bit. And send the 5th version . Thanks. Qing > > Richard. > >> thanks. >> >> Qing >> >>> On Mar 10, 2023, at 8:48 AM, Qing Zhao via Gcc-patches &

Re: [V4][PATCH 2/2] Update documentation to clarify a GCC extension

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:

Re: Question on patch -fprofile-partial-training

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

Re: Question on patch -fprofile-partial-training

> 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

Re: Question on patch -fprofile-partial-training

> 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

[V7][PATCH 0/2]Accept and Handle the case when a structure including a FAM nested in another structure

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

[V7][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

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

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

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

Re: [V7][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

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

Re: [V7][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

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 >

Re: [V7][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

ote: > > On Fri, 19 May 2023, Qing Zhao via Gcc-patches wrote: > >> +GCC extension accepts a structure containing an ISO C99 @dfn{flexible array > > "The GCC extension" or "A GCC extension". > >> +@item >> +A structure containing a C99 flexib

[PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

GCC extension accepts the case when a struct with a C99 flexible array member is embedded into another struct or union (possibly recursively) as the last field. __builtin_object_size should treat such struct as flexible size. gcc/c/ChangeLog: PR tree-optimization/101832 * c-decl.c

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

on a structure with a C99 flexible array member being nested in another structure. "The GCC extension accepts a structure containing an ISO C99 "flexible array member", or a union containing such a structure (possibly recursively) to be a member of a structure. There are two situations: * A

[V8][PATCH 0/2]Accept and Handle the case when a structure including a FAM nested in another structure

Hi, This is the 8th version of the patch, which rebased on the latest trunk. This is an important patch needed by Linux Kernel security project. compared to the 7th version, the major change are: 1. update the documentation wordings based on Joseph's suggestions. 2. change the name of the new ma

Re: [V7][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

t; 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 >>>> is embedded into another struct or union (possibly rec

[V8][PATCH 1/2] Handle component_ref to a structre/union field including flexible array member [PR101832]

GCC extension accepts the case when a struct with a C99 flexible array member is embedded into another struct or union (possibly recursively) as the last field. __builtin_object_size should treat such struct as flexible size. gcc/c/ChangeLog: PR tree-optimization/101832 * c-decl.c

[V8][PATCH 0/2]Accept and Handle the case when a structure including a FAM nested in another structure

(Resend due to the previous patches didn't include the version number) Hi, This is the 8th version of the patch, which rebased on the latest trunk. This is an important patch needed by Linux Kernel security project. compared to the 7th version, the major change are: 1. update the documentation w

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

on a structure with a C99 flexible array member being nested in another structure. "The GCC extension accepts a structure containing an ISO C99 "flexible array member", or a union containing such a structure (possibly recursively) to be a member of a structure. There are two situations: * A

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

Hi, This patch set introduces a new attribute "element_count" to annotate bounds for C99 flexible array member. A gcc bugzilla PR108896 has been created to record this task: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 A nice writeup "Bounded Flexible Arrays in C" https://people.kernel.

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

'element_count ("COUNT")' The 'element_count' 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

[V1][PATCH 2/3] Use the element_count atribute info in builtin object size [PR108896].

2023-05-17 Qing Zhao gcc/ChangeLog: PR C/108896 * tree-object-size.cc (addr_object_size): Use the element_count attribute info. * tree.cc (component_ref_has_element_count_p): New function. (component_ref_get_element_count): New function. * tree.h (

[V1][PATCH 3/3] Use the element_count attribute information in bound sanitizer[PR108896]

2023-05-17 Qing Zhao gcc/c-family/ChangeLog: PR C/108896 * c-ubsan.cc (ubsan_instrument_bounds): Use element_count attribute information. gcc/testsuite/ChangeLog: PR C/108896 * gcc.dg/ubsan/flex-array-element-count-bounds.c: New test. --- gcc/c-family/c

Re: [V8][PATCH 2/2] Update documentation to clarify a GCC extension [PR77650]

> On May 25, 2023, at 4:51 PM, Joseph Myers wrote: > > The documentation in this case is OK, though claims about how a future > version will behave have a poor track record (we tend to end up with such > claims persisting in the documentation even though the change in question > didn't get

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

ESCAPED NONLOCAL index colour1 } same as CALLUSED(69) callarg(71) = { ESCAPED NONLOCAL } callarg(72) = { ESCAPED NONLOCAL } callarg(73) = { ESCAPED NONLOCAL } callarg(74) = { ESCAPED NONLOCAL colour1 } My question: Is it possible to adjust alias analysis to resolve this issue? thanks. Qing

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

> On Feb 2, 2021, at 1:43 AM, Richard Biener wrote: > > On Mon, 1 Feb 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion. >> >> And now the routine “bump_map” in 511.povray is like following: >> ... >> >> # DEBUG BEGI

Re: The performance data for two different implementation of new security feature -ftrivial-auto-var-init

2, 2021, at 9:17 AM, Qing Zhao via Gcc-patches wrote: > > > >> On Feb 2, 2021, at 1:43 AM, Richard Biener wrote: >> >> On Mon, 1 Feb 2021, Qing Zhao wrote: >> >>> Hi, Richard, >>> >>> I have adjusted SRA phase to split calls to DEFER

PR 96391? Can we fix it for gcc11?

Hi, The bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 Bug 96391 - [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359 has been opened on 7/30/2020, and multiple users reported the sa

Re: PR 96391? Can we fix it for gcc11?

Richard, Thank you for the reply. Yes, I understand that without a working testing case to repeat the error, it’s very hard to debug and fix the issue. However, providing a testing case for this bug is really challenging from our side due to multiple reasons… I will discuss with our building

Testing case for fix-point type auto variables?

Hi, I am trying to add testing cases for verifing pattern initialization or zero initialization to fix-point type auto variables. Please let me know where in the test suite directory I can find a good example for fix-point type programming? Thanks. Qing

Re: PR 96391? Can we fix it for gcc11?

> On Feb 9, 2021, at 11:36 AM, Richard Biener wrote: > > On Tue, 9 Feb 2021, Qing Zhao wrote: > >> Richard, >> >> Thank you for the reply. >> >> Yes, I understand that without a working testing case to repeat the error, >> it’s very hard to debug and fix the issue. >> >> However, providi

Re: [PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

Hello, What’s the status of this patch now? Is there any major technical issue with the patch? Our company has been waiting for this patch for almost one year, we need it for our important application. Could this one be approved and committed to gcc11? Thanks. Qing > On Feb 5, 2021, at 3:34

[RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

(CC’ing Kees Cook on this topic) Hi, This is the first version of the complete patch for the new security feature for GCC: Initialize automatic variables with new first class option -ftrivial-auto-var-init=[uninitialized|pattern|zero] and a new variable attribute “uninitialized” to exclude

Re: PR 96391? Can we fix it for gcc11?

Hi, Richard, > On Feb 9, 2021, at 11:36 AM, Richard Biener wrote: > > On Tue, 9 Feb 2021, Qing Zhao wrote: >> >> Yes, I understand that without a working testing case to repeat the error, >> it’s very hard to debug and fix the issue. >> >> However, providing a testing case for this bug is re

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Kees, Thanks a lot for your testings on linux kernel. I am happy to know that the initial implementation works fine. I will study the padding case and the switch case to fix the issues there. > On Feb 24, 2021, at 10:41 PM, Kees Cook wrote: > > (please keep me in CC, I'm not subscribed...

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Kees, Just noticed that you didn’t add -fauto-var-init-approach=D to the command line. [qinzhao@localhost uninit]$ cat t8.c a() { char b[1]; } [qinzhao@localhost uninit]$ sh t /home/qinzhao/Install/latest/bin/gcc -ftrivial-auto-var-init=pattern -fauto-var-init-approach=D t8.c -S t8.c:1:1: war

Re: [RFC][patch for gcc12][version 1] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Thanks. I will take a look and fix this issue. BTW, could you please also re-test -ftrivial-auto-var-init=zero -fauto-var-init-approach=D too? And let me know are there new issues for -ftrivial-auto-var-init=zero? (FYI, I have tested -ftrivial-auto-var-init=zero -fauto-var-init-approach=D and a

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, Thanks a lot for you review. Although these comments are not made on the latest patch (7th version) :-), all the comments are valid since the parts you commented are not changed in the 7th version. > On Aug 9, 2021, at 9:09 AM, Richard Biener wrote: > > On Tue, 27 Jul 2021, Qing

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Aug 10, 2021, at 2:36 AM, Richard Biener wrote: > > On Mon, 9 Aug 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for you review. >> >> Although these comments are not made on the latest patch (7th version) :-), >> all the comments are valid since the parts you commented >>

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, > On Aug 10, 2021, at 9:16 AM, Richard Biener wrote: > > On Tue, 10 Aug 2021, Qing Zhao wrote: > > > +static void > +expand_DEFERRED_INIT (internal_fn, gcall *stmt) > +{ > + tree var = gimple_call_lhs (stmt); > + tree size_of_var = gimple_call_arg (stmt, 0); >

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Aug 10, 2021, at 10:22 AM, Richard Biener wrote: > > On Tue, 10 Aug 2021, Qing Zhao wrote: > >> Hi, >> >>> On Aug 10, 2021, at 9:16 AM, Richard Biener wrote: >>> >>> On Tue, 10 Aug 2021, Qing Zhao wrote: >>> >>> >>> +static void >>> +expand_DEFERRED_INIT (internal_fn, gca

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, > On Aug 10, 2021, at 10:22 AM, Richard Biener wrote: >>> >>> Especially in the VLA case but likely also in general (though unlikely >>> since usually the receiver of initializations are simple enough). I'd >>> expect the VLA case end up as >>> >>> *ptr_to_decl = .DEFERRED_INIT (.

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches > wrote: > > Hi, Richard, > >> On Aug 10, 2021, at 10:22 AM, Richard Biener wrote: >>>> >>>> Especially in the VLA case but likely also in general (though unlikely >>>> since

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Aug 11, 2021, at 2:02 AM, Richard Biener wrote: > > On Tue, 10 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> Hi, Richard, >>> >>>>

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Aug 11, 2021, at 4:02 AM, Richard Sandiford > wrote: > > Qing Zhao via Gcc-patches writes: >>> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> Hi, Richard, >>> >>>> On Aug 10, 2021, at

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Aug 11, 2021, at 8:37 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 11, 2021, at 2:02 AM, Richard Biener wrote: >>> >>> On Tue, 10 Aug 2021, Qing Zhao wrote: >>> >>>

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

>> >>>> >>>>> On Aug 11, 2021, at 2:02 AM, Richard Biener wrote: >>>>> >>>>> On Tue, 10 Aug 2021, Qing Zhao wrote: >>>>> >>>>>> >>>>>> >>>>>>> On Aug 10, 2021, at 3:16

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

02 AM, Richard Biener wrote: >>>>> >>>>> On Tue, 10 Aug 2021, Qing Zhao wrote: >>>>> >>>>>> >>>>>> >>>>>>> On Aug 10, 2021, at 3:16 PM, Qing Zhao via Gcc-patches >>>>>>&

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

RED_INIT making the LHS address taken > which I think could be achieved by passing it the address as argument instead > of having a LHS. But let's not go down this route - it will have quite bad > behavior on alias analysis and optimization. Okay. Qing > >> If

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

> On Aug 11, 2021, at 11:15 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Aug 11, 2021, at 4:02 AM, Richard Sandiford >>> wrote: I came up with the following solution: Define the IFN_DEFERRED_INIT function as: LHS = DEFERRED_INIT (SIZE of the DECL,

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

uto_var” is >> uninitialized. > > Yes. Basically if there's an artificial variable auto initialized you have to > look at its uses. Okay. > >> 2. During RTL expansion, following the data flow to connect .DEFERRED_INIT >> to “auto_var”,

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

nnect >> .DEFERRED_INIT to “auto_var”, and then decide that “auto_var” is >> uninitialized. > > Yes. Basically if there's an artificial variable auto initialized you have to > look at its uses. > >> 2. During RTL expansion, following the data flow to connect .DEFERRED_INI

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

s not need any change. Everything works well. And I believe that treating “call to .DEFERRED_INIT” as “is_gimple_val” is reasonable since this call actually is a constant. Let me know if you have any objection on this solution. thanks. Qing > On Aug 11, 2021, at 3:30 PM, Qing Zhao via Gcc-pa

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, Richard, For RTL expansion of call to .DEFERRED_INIT, I changed my code per your suggestions like following: == #define INIT_PATTERN_VALUE 0xFE static void expand_DEFERRED_INIT (internal_fn, gcall *stmt) { tree lhs = gimple_call_lhs (stmt); tree var_size = gimple_cal

Re: [patch][version 6] add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

al_bytes; i++) CONSTRUCTOR_APPEND_ELT (elts, NULL_TREE, element); pattern = build_constructor (array_type, elts); pattern = build1 (VIEW_CONVERT_EXPR, var_type, pattern); } } Thanks. Qing On Aug 12, 2021, at 2:24 PM, Qing Zhao via Gcc

<    1   2   3   4   5   6   7   8   >