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 s

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

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

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

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

[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<mailto:ja...@redhat.com>, rguent...@suse.de<mailto:rguent...@suse.de> Cc: gcc-patches@gcc.

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

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 +0000, Qing Zhao wrote: >> Understood. >> So, your patch fixed this bug, and then [0] arrays are instrumented by >> default with this patch. >> >>> Well, it

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

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 s

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 c

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

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

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]

> 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

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]

> On May 25, 2023, at 1:41 AM, Bernhard Reutner-Fischer > wrote: > > On 24 May 2023 16:09:21 CEST, Qing Zhao wrote: >> Bernhard, >> >> Thanks a lot for your comments. >> >>> On May 19, 2023, at 7:11 PM, Bernhard Reutner-Fischer >>&g

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

n_dynamic_object_size and array bound sanitizer to detect out-of-bound errors for flexible array member references. 2023-05-17 Qing Zhao gcc/c-family/ChangeLog: PR C/108896 * c-attribs.cc (handle_element_count_attribute): New function. * c-common.cc (c_flexible_array_mem

[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

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

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?

building engineer to see what we can do. Or, I will try to debug and fix this issue myself… Qing > On Feb 9, 2021, at 2:18 AM, Richard Biener wrote: > > On Mon, 8 Feb 2021, Qing Zhao wrote: > >> Hi, >> >> The bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 &g

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

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

ue, I will delete the code related to “A” in the next version. There are several places, I put “FIXME” in the comments, please review those part and let me know any issues with those parts. ***Changelog: gcc/ChangeLog: 2021-02-17 qing zhao mailto:qing.z...@oracle.com>>

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

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

not subscribed...) Yes, I will. > > On Thu Feb 18, 2021 Qing Zhao said: >> Initialize automatic variables with new first class option >> -ftrivial-auto-var-init=[uninitialized|pattern|zero] > > Yay! I'm really excited to see this. Thank you for working on > it!

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

. Sorry for the confusion. > On Feb 25, 2021, at 2:00 PM, Kees Cook wrote: > > On Thu, Feb 25, 2021 at 12:15:01PM -0600, Qing Zhao wrote: >>> On Feb 24, 2021, at 10:41 PM, Kees Cook wrote: >>> [...] >>> test_stackinit: trailing_hole_none ok >>> test

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

also -ftrivial-auto-var-init=pattern -fauto-var-init-approach=D on cpu2017, without any issue). Thanks a lot for your help. Qing On Feb 26, 2021, at 3:42 PM, Kees Cook wrote: > > On Thu, Feb 25, 2021 at 05:56:38PM -0600, Qing Zhao wrote: >> Just noticed that you didn’t add -fa

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

Jul 2021, Qing Zhao wrote: > >> Hi, >> >> This is the 6th version of the patch for the new security feature for GCC. >> >> I have tested it with bootstrap on both x86 and aarch64, regression testing >> on both x86 and aarch64. >> Also compile CPU2017

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

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) >>>>> +{ >>>>> +

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

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 8:58 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 11, 2021, at 8:37 AM, Richard Biener wrote: >>> >>> On Wed, 11 Aug 2021, Qing Zhao wrote: >>> >>

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

.DEFERRED_INIT purpose when the auto var is address taken? If so, “uninitialized analysis” phase need to be further adjusted to specially handle such IR. If not, what should we do when the auto var is address taken? Thanks a lot. Qing > On Aug 11, 2021, at 8:58 AM, Richard Biener wr

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

> On Aug 11, 2021, at 10:53 AM, Richard Biener wrote: > > On August 11, 2021 5:30:40 PM GMT+02:00, Qing Zhao > wrote: >> I modified the routine “gimple_add_init_for_auto_var” as the following: >> >> /* Generate initialization to automatic variable DECL b

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_I

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

> On Aug 11, 2021, at 11:55 AM, Richard Biener wrote: > > On August 11, 2021 6:22:00 PM GMT+02:00, Qing Zhao > wrote: >> >> >>> On Aug 11, 2021, at 10:53 AM, Richard Biener wrote: >>> >>> On August 11, 2021 5:30:40 PM GMT+02:00,

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

Any comments and suggestions on this issue? Qing j > On Aug 11, 2021, at 11:55 AM, Richard Biener wrote: > > On August 11, 2021 6:22:00 PM GMT+02:00, Qing Zhao > wrote: >> >> >>> On Aug 11, 2021, at 10:53 AM, Richard Biener wrote: >>> >>>

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

Thanks a lot for the help. Qing > On Aug 9, 2021, at 9:09 AM, Richard Biener wrote: > > On Tue, 27 Jul 2021, Qing Zhao wrote: > > +created during gimplification phase. Refer to gimplify_vla_decl > +for details. */ > + tree var_decl = (TREE_CODE (var

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

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

> On Aug 16, 2021, at 2:12 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> Hi, >> >> I finally decided to take another approach to resolve this issue, it >> resolved all the potential issues with the “address taken” auto variabl

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

> On Aug 16, 2021, at 10:08 AM, Richard Biener wrote: > > On August 16, 2021 4:48:16 PM GMT+02:00, Qing Zhao > wrote: >> >> >>> On Aug 16, 2021, at 2:12 AM, Richard Biener wrote: >>> >>> On Wed, 11 Aug 2021, Qing Zhao wrote: >>

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

> On Aug 16, 2021, at 2:40 AM, Richard Biener wrote: > > On Thu, 12 Aug 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> For RTL expansion of call to .DEFERRED_INIT, I changed my code per your >> suggestions like following: >> >> ==

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

> On Aug 16, 2021, at 2:11 AM, Richard Biener wrote: > > On Wed, 11 Aug 2021, Qing Zhao wrote: > >> Hi, >> >> I met another issue for “address taken” auto variable, see below for details: >> >> the testing case: (gcc/testsuite/gcc.dg/unini

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

> On Aug 16, 2021, at 2:40 AM, Richard Biener wrote: > > On Thu, 12 Aug 2021, Qing Zhao wrote: > >> Hi, Richard, >> >> For RTL expansion of call to .DEFERRED_INIT, I changed my code per your >> suggestions like following: >> >> ==

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

> On Aug 17, 2021, at 3:43 AM, Richard Biener wrote: > > On Mon, 16 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 16, 2021, at 2:40 AM, Richard Biener wrote: >>> >>> On Thu, 12 Aug 2021, Qing Zhao wrote: >>> >>>>

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

> On Aug 17, 2021, at 3:29 AM, Richard Biener wrote: > > On Mon, 16 Aug 2021, Qing Zhao wrote: > >> My current code for expand_DEFERRED_INIT is like the following, could you >> check and see whether there is any issue for it: >> >> #define INI

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

> On Aug 17, 2021, at 9:45 AM, Richard Biener wrote: > > On Tue, 17 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 17, 2021, at 3:43 AM, Richard Biener wrote: >>> >>> On Mon, 16 Aug 2021, Qing Zhao wrote: >>> >>

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

> On Aug 16, 2021, at 11:48 AM, Qing Zhao via Gcc-patches > wrote: > >>> From the above IR file after “FRE”, we can see that the major issue with >>> this IR is: >>> >>> The address taken auto variable “alt_reloc” has been completely replac

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

> On Aug 17, 2021, at 9:50 AM, Qing Zhao via Gcc-patches > wrote: > > > >> On Aug 17, 2021, at 3:29 AM, Richard Biener wrote: >> >> On Mon, 16 Aug 2021, Qing Zhao wrote: >> >>> My current code for expand_DEFERRED_INIT is like the followin

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

> On Aug 17, 2021, at 10:04 AM, Qing Zhao via Gcc-patches > wrote: > > > >> On Aug 16, 2021, at 11:48 AM, Qing Zhao via Gcc-patches >> wrote: >> >>>> From the above IR file after “FRE”, we can see that the major issue with >>>&g

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

> On Aug 18, 2021, at 2:19 AM, Richard Biener wrote: > > On Tue, 17 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 17, 2021, at 10:04 AM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> >>> >>>> On Aug 16,

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

> On Aug 18, 2021, at 2:15 AM, Richard Biener wrote: > > On Tue, 17 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 17, 2021, at 9:50 AM, Qing Zhao via Gcc-patches >>> wrote: >>> >>> >>> >>>> On Aug 17, 2

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

> On Aug 19, 2021, at 4:00 AM, Richard Biener wrote: > > On Wed, 18 Aug 2021, Qing Zhao wrote: > >> >> >>> On Aug 18, 2021, at 2:15 AM, Richard Biener wrote: >>> >>> On Tue, 17 Aug 2021, Qing Zhao wrote: >>> >>>

[Patch][doc][PR101843]clarification on building gcc and binutils together

rom 9bf6f9a5964df26cac32d90f57719f4871874d54 Mon Sep 17 00:00:00 2001 From: qing zhao Date: Thu, 19 Aug 2021 18:20:49 -0400 Subject: [PATCH] doc/install.texi: add a generic advice on building gcc and binutils together. gcc/ChangeLog: * doc/install.texi: Add a generic advice on building gcc and binutils together. --- gcc/doc/install.t

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

> On Aug 19, 2021, at 8:54 AM, Qing Zhao via Gcc-patches > wrote: > >>>>> Breakpoint 1, expand_DEFERRED_INIT (stmt=0x7fffe96ae348) at >>>>> ../../latest-gcc/gcc/internal-fn.c:3021 >>>>> 3021mark_addressable (lhs); >>&g

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 11, 2020, at 3:36 PM, Segher Boessenkool > wrote: > > On Fri, Sep 11, 2020 at 03:17:19PM -0500, Qing Zhao wrote: >>> On Sep 11, 2020, at 3:05 PM, Segher Boessenkool >>> wrote: >>> On Fri, Sep 11, 2020 at 02:40:06PM -0500, Qing Zhao wrote: >

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 11, 2020, at 4:03 PM, Segher Boessenkool > wrote: > > Hi! > > On Fri, Sep 11, 2020 at 03:14:57PM -0500, Qing Zhao wrote: >> My understanding of how this scheme helps ROP is: the attacker usually uses >> scratch register to pass > > Help obs

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Sep 11, 2020, at 4:44 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >>> On Sep 11, 2020, at 12:32 PM, Richard Sandiford >>> >> If we go for (2), then I think it would be better to do >>> it at the start of pass_late_compilation i

<    5   6   7   8   9   10   11   12   13   14   >