[PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

Hi, This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515 It's possible that the TYPE_NAME of a record_type is NULL, therefore when printing the TYPE_NAME, we should check and handle this special case.

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

> On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote: > > On 2/8/22 15:11, Qing Zhao wrote: >> Hi, >> This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at >> cp/cxx-pretty-print.c:128) >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515 >> It's possible that the TYPE_NAME of a

Re: [Patch]middle-end: updating the reg use in exit block for -fzero-call-used-regs [PR100775]

> On Feb 9, 2022, at 10:20 AM, Richard Sandiford > wrote: > > Qing Zhao writes: >> Hi, Richard, >> >> Could you please review this patch? This is a fix to the previous >> -fzero-call-used-regs implementation. >> >> PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with >

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

> On Feb 9, 2022, at 12:23 PM, Jason Merrill wrote: > > On 2/9/22 10:51, Qing Zhao wrote: >>> On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote: >>> >>> On 2/8/22 15:11, Qing Zhao wrote: Hi, This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

Hi, Jason, On Feb 9, 2022, at 3:01 PM, Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> wrote: On Feb 9, 2022, at 12:23 PM, Jason Merrill mailto:ja...@redhat.com>> wrote: On 2/9/22 10:51, Qing Zhao wrote: On Feb 8, 2022, at 4:20 PM, Jason Merrill mailto:ja...@redhat

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

Hi, Jason, > On Feb 11, 2022, at 11:27 AM, Jason Merrill wrote: Sure, we might as well make this code more robust. But we can do better than if we check TYPE_PTRMEMFUNC_P. >>> Okay, so what should we print to the user if it's “TYPE_PTRMEMFUNC_P”? >>> Print nothing or some spec

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

> On Feb 11, 2022, at 1:39 PM, Jason Merrill wrote: > > On 2/11/22 13:11, Qing Zhao wrote: >> Hi, Jason, >>> On Feb 11, 2022, at 11:27 AM, Jason Merrill wrote: >> >> Sure, we might as well make this code more robust. But we can do better >> than if we check TYPE_PTRMEMFUNC_P. >

Re: [PATCH] Fix PR 101515 (ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128)

> On Feb 11, 2022, at 3:54 PM, Jason Merrill wrote: > > On 2/11/22 15:29, Qing Zhao wrote: >>> On Feb 11, 2022, at 1:39 PM, Jason Merrill wrote: >>> >>> On 2/11/22 13:11, Qing Zhao wrote: Hi, Jason, > On Feb 11, 2022, at 11:27 AM, Jason Merrill wrote: Sure, we mig

Re: [PATCH] fold, simplify-rtx: Punt on non-representable floating point constants [PR104522]

> On Feb 15, 2022, at 3:58 AM, Jakub Jelinek wrote: > > Hi! > > For IBM double double I've added in PR95450 and PR99648 verification that > when we at the tree/GIMPLE or RTL level interpret target bytes as a REAL_CST > or CONST_DOUBLE constant, we try to encode it back to target bytes and > v

[PATCH 1/2][middle-end/102276] Don't emit switch-unreachable warnings for -ftrivial-auto-var-init (PR102276)

Hi, Per our discussion in the bug report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 We decided to go with the following solution: 1. avoid emitting switch-unreachable warnings for -ftrivial-auto-var-init; 2. adding a new option -Wtrivial-auto-var-init to emit warnings for the switch-u

[PATCH 2/2][middle-end/102276] Adding -Wtrivial-auto-var-init and update documentation.

Hi, This is the 2nd patch for fixing pr102276. Adding -Wtrivial-auto-var-init and update documentation. Adding a new warning option -Wtrivial-auto-var-init to report cases when -ftrivial-auto-var-init cannot initialize the auto variable. At the same time, update documentation for -ftrivial-auto-

Re: [PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

Peter, Thanks a lot for the patch. Richard, how do you think of the patch? (The major concern for me is: With the current patch proposed by Peter, we will generate the call to .DEFERRED_INIT for a variable with OPAQUE_TYPE during gimplification phase, However, if this

Re: [PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

> On Nov 30, 2021, at 9:14 AM, Peter Bergner wrote: > > On 11/30/21 2:37 AM, Richard Biener wrote: >> On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote: >> I think that's inconsistent indeed. Peter, what are "opaque" >> registers? rs6000-modes.def suggests >> that there's __vector_pair and _

Re: [PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

> On Nov 30, 2021, at 2:37 AM, Richard Biener > wrote: > > On Mon, Nov 29, 2021 at 11:56 PM Qing Zhao wrote: >> >> Peter, >> >> Thanks a lot for the patch. >> >> Richard, how do you think of the patch? >> >> (The major concern for me is: >> >>With the current patch proposed by Pe

Re: [PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

> On Nov 30, 2021, at 12:08 PM, Peter Bergner wrote: > > On 11/30/21 11:51 AM, Qing Zhao wrote: >> So, looks like that the variable with OPAQUE_TYPE cannot be all explicitly >> initialized even at source code level. >> >> The only way to initialize such variable (only __vector_quad, not for

Re: [PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

PM, Qing Zhao via Gcc-patches wrote: >>> void >>> bar (__vector_pair *dst, __vector_pair *src) >>> { >>> __vector_pair pair; >>> pair = *src; >>> ... >>> } >> >> However, even with the above, the memory pointed by “src

Re: [PATCH] middle-end: Skip initialization of opaque type register variables [PR103127]

> On Dec 1, 2021, at 3:01 AM, Richard Biener wrote: > > On Tue, Nov 30, 2021 at 11:35 PM Peter Bergner wrote: >> >> On 11/30/21 2:44 PM, Qing Zhao via Gcc-patches wrote: >>> Sorry for the confusing… >>> My major question is: >>> >>>

[RFC]PR103271 ICE in assign_stack_temp_for_type with -ftrivial-auto-var-init=pattern and VLAs and -mno-strict-align on riscv64

Hi, As I studied, the issue with this bug is similar as PR102285: For the testing case: int qy (void) { int tw = 4; int fb[tw]; return fb[2]; /* { dg-warning "uninitialized" } */ } if compiled with /home/opc/Install/cross/bin/riscv64-unknown-linux-gnu-gcc -c -O1 -mno-strict-align -ft

[Patch]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables

Hi, This patch is to resolve the following two issues in the current implemenation of -ftrivial-auto-var-init: 1. The 3rd parameter of function .DEFERRED_INIT is IS_VLA currently, which is not needed at all; 2. The address taken variable is replaced with a temporary variable during gimplifi

Re: [Patch]Enable -Wuninitialized + -ftrivial-auto-var-init for address taken variables

Hi, Martin, Thanks a lot for your review and comments. > On Dec 9, 2021, at 11:43 AM, Martin Sebor wrote: >> >> diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c >> index 1df0bcc42c0..85d1ba866fc 100644 >> --- a/gcc/tree-ssa-uninit.c >> +++ b/gcc/tree-ssa-uninit.c >> @@ -182,9 +182,22

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

Hi, Alexandre, Could you please explain a little bit on the motivation of this patch first? thanks. Qing > On Oct 21, 2022, at 3:31 AM, Alexandre Oliva wrote: > > Introduce 'leafy' to auto-select between 'used' and 'all' for leaf and > nonleaf functions, respectively. > > Regstrapped on x86_

[RFC] how to handle the combination of -fstrict-flex-arrays + -Warray-bounds

Hi, (FAM below refers to Flexible Array Members): I need inputs on how to handle the combination of -fstrict-flex-arrays + -Warray-bounds. Our initial goal is to update -Warray-bounds with multiple levels of -fstrict-flex-arrays=N to issue warnings according to the different levels of “N”.

Re: [RFC] how to handle the combination of -fstrict-flex-arrays + -Warray-bounds

> On Oct 22, 2022, at 12:54 PM, Martin Sebor wrote: > > On 10/21/22 09:29, Qing Zhao wrote: >> Hi, >> (FAM below refers to Flexible Array Members): >> I need inputs on how to handle the combination of -fstrict-flex-arrays + >> -Warray-bounds. >> Our initial goal is to update -Warray-bounds wi

Re: [RFC] how to handle the combination of -fstrict-flex-arrays + -Warray-bounds

> On Oct 24, 2022, at 3:30 AM, Richard Biener wrote: > > On Sat, 22 Oct 2022, Martin Sebor wrote: > >> On 10/21/22 09:29, Qing Zhao wrote: >>> Hi, >>> >>> (FAM below refers to Flexible Array Members): >>> >>> I need inputs on how to handle the combination of -fstrict-flex-arrays + >>> -Warr

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

Hi, Alexandre, > On Oct 24, 2022, at 10:48 PM, Alexandre Oliva wrote: > > Hello, Qing, > > It was a pleasure to meet you at the Cauldron. Me too! > > > On Oct 21, 2022, Qing Zhao wrote: > >> Hi, Alexandre, >> Could you please explain a little bit on the motivation of this patch first? > >

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

> On Oct 26, 2022, at 5:29 PM, Alexandre Oliva wrote: > > On Oct 25, 2022, Qing Zhao wrote: > >>> 'all' for leaf functions is likely wasteful. If no other functions are >>> called, one can determine exactly which registers might carry >>> information out and thus need zeroing, and 'used' is

Re: Where in C++ module streaming to handle a new bitfield added in "tree_decl_common"

> On Aug 15, 2022, at 9:28 AM, Nathan Sidwell wrote: > > On 8/2/22 10:44, Qing Zhao wrote: >> Hi, Nathan, >> I am adding a new bitfield “decl_not_flexarray” in “tree_decl_common” >> (gcc/tree-core.h) for the new gcc feature -fstrict-flex-arrays. >> >> diff --git a/gcc/tree-core.h b/gcc/t

Re: Where in C++ module streaming to handle a new bitfield added in "tree_decl_common"

> On Aug 16, 2022, at 8:37 AM, Richard Biener > wrote: > > On Tue, Aug 16, 2022 at 2:16 PM Nathan Sidwell wrote: >> >> On 8/15/22 10:03, Richard Biener wrote: >>> On Mon, Aug 15, 2022 at 3:29 PM Nathan Sidwell via Gcc-patches >>> wrote: On 8/2/22 10:44, Qing Zhao wrote: > Hi,

[GCC13][Patch][V3][0/2]Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

Hi, This is the 3rd version of the patch set. Compare to the 2nd version, the following are the major change: 1. change the name of the option from -fstrict-flex-array to -fstrict-flex-arrays (per Kees' suggestion, this will be consistent with LLVM's option); 2. -std=c89 and ISO C++ will d

[[GCC13][Patch][V3] 2/2] Use array_at_struct_end_p in __builtin_object_size [PR101836]

Use array_at_struct_end_p to determine whether the trailing array of a structure is flexible array member in __builtin_object_size. gcc/ChangeLog: PR tree-optimization/101836 * tree-object-size.cc (addr_object_size): Use array_at_struct_end_p to determine a flexible array

[[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Add the following new option -fstrict-flex-array[=n] and a corresponding attribute strict_flex_array to GCC: '-fstrict-flex-array' Treat the trailing array of a structure as a flexible array member in a stricter way. The positive form is equivalent to '-fstrict-flex-array=3', which

Re: [[GCC13][Patch][V3] 2/2] Use array_at_struct_end_p in __builtin_object_size [PR101836]

> On Aug 26, 2022, at 4:49 AM, Richard Biener wrote: > > On Wed, 17 Aug 2022, Qing Zhao wrote: > >> Use array_at_struct_end_p to determine whether the trailing array >> of a structure is flexible array member in __builtin_object_size. > > With the discussion about what array_at_struct_end_p

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 26, 2022, at 4:48 AM, Richard Biener wrote: > > On Wed, 17 Aug 2022, Qing Zhao wrote: > >> Add the following new option -fstrict-flex-array[=n] and a corresponding >> attribute strict_flex_array to GCC: >> >> '-fstrict-flex-array' >> Treat the trailing array of a structure as a f

Fwd: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Hi, Joseph and Nathan, Could you please review the C and C++ FE parts of the patch? https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html The middle-end changes have been approved by Richard already. https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600379.html Thanks. Begin

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Hi, Joseph, Thanks a lot for your comment. > On Aug 30, 2022, at 6:53 PM, Joseph Myers wrote: > > On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote: > >> Hi, Joseph and Nathan, >> >> Could you please review the C and C++ FE parts of the patch? >>

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote: > > On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote: > >>> "a GNU extension" suggests a particular language feature, but I think >>> you're actually referring here to a whole language v

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 31, 2022, at 2:55 PM, Qing Zhao via Gcc-patches > wrote: > > > >> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote: >> >> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote: >> >>>> "a GNU extension" suggests a p

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 31, 2022, at 3:29 PM, Joseph Myers wrote: > > On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote: > >>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify >>> -std=c89? How for -std=gnu89? >> >> 1. what’s the major

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 31, 2022, at 3:52 PM, Joseph Myers wrote: > > On Wed, 31 Aug 2022, Qing Zhao wrote: > >> Does the above mean that -std=gnu89 does not support C99 flexible array >> member, then > > No. > > Flexible array members are supported by GCC in all C standards modes. The > C90 standard d

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Okay, I am fine with this. Richard and Kees, what’s your opinion on this? thanks. Qing > On Aug 31, 2022, at 4:09 PM, Joseph Myers wrote: > > On Wed, 31 Aug 2022, Qing Zhao wrote: > When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member [] is treated as a valid f

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

> On Aug 31, 2022, at 4:16 PM, Qing Zhao via Gcc-patches > wrote: > > Okay, I am fine with this. Another thought on this is: One of the major purposes of the new option -fstrict-flex-array is to encourage standard conforming programming style. So, it might be reasonable to tr

Re: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and new attribute strict_flex_array

Okay, then I will delete those new warnings I added in the version 3 of the patch. Thanks. Qing > On Sep 1, 2022, at 2:11 AM, Richard Biener wrote: > > On Wed, 31 Aug 2022, Kees Cook wrote: > >> On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote: >>> One of the major purposes of the n

[GCC13][Patch][V4][PATCH 0/2] Add a new option -fstrict-flex-array[=n] and attribute strict_flex_array(n) and use it in PR101836

This is the 4th version of the patch set. Compare to the 3rd version, the following are the major change: 1. delete all the warnings for the confliction between -std and -fstrict-flex-arrays per our discussion. 2. delete all the related testing cases for these warnings. 3. update all the wording c

[GCC13][Patch][V4][PATCH 2/2] Use array_at_struct_end_p in __builtin_object_size [PR101836]

Use array_at_struct_end_p to determine whether the trailing array of a structure is flexible array member in __builtin_object_size. gcc/ChangeLog: PR tree-optimization/101836 * tree-object-size.cc (addr_object_size): Use array_at_struct_end_p to determine a flexible array

[GCC13][Patch][V4][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_arrays

Add the following new option -fstrict-flex-arrays[=n] and a corresponding attribute strict_flex_arrays to GCC: '-fstrict-flex-arrays' Treat the trailing array of a structure as a flexible array member in a stricter way. The positive form is equivalent to '-fstrict-flex-arrays=3', w

[patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

Hi, As Kee’s requested in this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 = Currently -fzero-call-used-regs will use a pattern of: XOR regA,regA MOV regA,regB MOV regA,regC ... RET However, this introduces both a register ordering dependency (e.g. the CPU cannot clear regB w

Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

> On May 6, 2022, at 10:58 AM, Uros Bizjak wrote: > > On Fri, May 6, 2022 at 4:29 PM Qing Zhao wrote: >> >> Hi, >> >> As Kee’s requested in this PR: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101891 >> >> = >> >> Currently -fzero-call-used-regs will use a pattern of: >> >> XOR r

Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

> On May 7, 2022, at 4:06 AM, Uros Bizjak wrote: > > On Fri, May 6, 2022 at 6:42 PM Qing Zhao wrote: >> >> >> >>> On May 6, 2022, at 10:58 AM, Uros Bizjak wrote: >>> >>> On Fri, May 6, 2022 at 4:29 PM Qing Zhao wrote: Hi, As Kee’s requested in this PR: https:/

Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

Another question: I think that this patch might need to be back ported to Gcc12 and GCC11. What’s your opinion on this? If so, when can I backport it? thanks. Qing > On May 7, 2022, at 4:06 AM, Uros Bizjak wrote: > > On Fri, May 6, 2022 at 6:42 PM Qing Zhao wrote: >> >> >> >>> On May 6,

Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

> On May 10, 2022, at 1:12 AM, Richard Biener wrote: > > On Mon, 9 May 2022, Uros Bizjak wrote: > >> On Mon, May 9, 2022 at 5:44 PM Qing Zhao wrote: >>> >>> Another question: >>> >>> I think that this patch might need to be back ported to Gcc12 and GCC11. >>> >>> What?s your opinion on th

Back porting to GCC11/GCC12: Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

Hi, I have added the patch to GCC11 and GCC12 in my local area and bootstrapped and regress tested on both x86 and aarch64, no any issues. Can I committed them to both GCC11 and GCC12 branches? Thanks. > On May 10, 2022, at 8:38 AM, Qing Zhao via Gcc-patches > wrote: > > &g

Re: Back porting to GCC11/GCC12: Re: [patch][gcc13][i386][pr101891]Adjust -fzero-call-used-regs to always use XOR

sted on both x86 and aarch64, no any issues. >> >> Can I committed them to both GCC11 and GCC12 branches? > > Yes. > > Thanks, > Richard. > >> Thanks. >> >> >> >> >>> On May 10, 2022, at 8:38 AM, Qing Zhao via Gcc-patches >

Re: Testsuite fails on PowerPC with: Re: [PATCH][middle-end][i386][version 6]Add -fzero-call-used-regs=[skip|used-gpr-arg|used-arg|all-gpr-arg|all-arg|used-gpr|all-gpr|used|all])

> On Nov 4, 2020, at 1:00 PM, Segher Boessenkool > wrote: > > On Wed, Nov 04, 2020 at 01:20:58PM +, Richard Sandiford wrote: >> Tobias Burnus writes: >>> Three of the testcases fail on PowerPC: >>> gcc.target/i386/zero-scratch-regs-{9,10,11}.c >>> powerpc64le-linux-gnu/default/gcc.d/z

[Patch][i386][PR97715]: Fix a bug when adding -fzero-call-used-regs=all with -mno-80387

As we discussed in the bug report, we should not zero stack registers when there is no x87 registers available. The following is the fix per Jakub’s suggestion. And I have tested it on X86. Okay for commit? thanks. Qing From 0080f104df2dc752969a1949981ba343f276e802 Mon Sep 17 00:00:00 2001

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

Jakub and Jeff, PING^7 on the following patch proposed 8 months ago for gcc11: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542198.html The deadline for gcc11 stage 1 is approaching. The pinged patch is one that has be

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

> On Nov 16, 2020, at 4:29 AM, Martin Liška wrote: > > On 11/10/20 9:53 PM, Qing Zhao wrote: >> The deadline for gcc11 stage 1 is approaching. The pinged patch is one that >> has been sent for review 8 months ago in order to >> Make into gcc11. > > Hello. > > You didn't miss the deadline a

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

Sorry for my late reply (I just came back from vacation last night). > On Aug 23, 2021, at 8:55 AM, Richard Biener wrote: > Looks like for the following code: 3026 if (!reg_lhs) 3027 { 3028 /* If this is a VLA or the variable is not in register, >>

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

Ping. Qing > On Aug 21, 2021, at 3:07 PM, Qing Zhao via Gcc-patches > wrote: > > Hi, > > This is the 8th 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 aarch6

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

Hi, Richard, Thanks a lot for your review. > On Sep 6, 2021, at 5:16 AM, Richard Biener wrote: > > On Sat, 21 Aug 2021, Qing Zhao wrote: > >> Hi, >> >> This is the 8th version of the patch for the new security feature for GCC. >> I have tested it with bootstrap on both x86 and aarch64, regres

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

> On Sep 7, 2021, at 11:57 AM, Qing Zhao via Gcc-patches > wrote: > > Hi, Richard, > > Thanks a lot for your review. > >> On Sep 6, 2021, at 5:16 AM, Richard Biener wrote: >> >> On Sat, 21 Aug 2021, Qing Zhao wrote: >> >>> Hi, >

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

ctory containing the GCC sources. -- 2.27.0 > On Aug 23, 2021, at 12:45 AM, Jeff Law via Gcc-patches > wrote: > > > > On 8/19/2021 4:27 PM, Qing Zhao via Gcc-patches wrote: >> Hi, >> >> This patch is on behalf of John Henning, who opened PR 101843: &g

[COMMITTED][patch][version 9]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

Hi, FYI I just committed the following patch to gcc upstream: https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/353195.html Thanks. Qing > On Sep 6, 2021, at 5:16 AM, Richard Biener wrote: > > On Sat, 21 Aug 2021, Qing Zhao wrote: > >> Hi, >> >> This is the 8th version of the patch fo

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

phe LYON > wrote: > > > On 10/09/2021 00:49, Qing Zhao via Gcc-patches wrote: >> Hi, FYI >> >> I just committed the following patch to gcc upstream: >> >> >> https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/353195.html >> > Hi, >

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

Hi, Thomas, Thanks for reporting the issue. > On Sep 10, 2021, at 4:40 AM, Thomas Schwinge wrote: > > Hi! > > On 2021-09-10T10:47:00+0200, Christophe LYON via Gcc-patches > wrote: >> On 10/09/2021 00:49, Qing Zhao via Gcc-patches wrote: >>> I just com

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

Hi, Richard, Jose, Yes, we will try to come up with a patch to gcc-12/changes.html for this feature. Thanks. Qing > On Sep 10, 2021, at 8:46 AM, Jose E. Marchesi via Gcc-patches > wrote: > > > Hi Richard. > >> On Thu, 9 Sep 2021, Kees Cook wrote: >> >>> On Thu, Sep 09, 2021 at 10:49:11PM

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

Fri, Sep 03, 2021 at 02:47:11PM +0000, Qing Zhao via Gcc-patches wrote: >>> 2021-08-20 qing zhao >>> >>> * c-c++-common/auto-init-1.c: New test. >>> * c-c++-common/auto-init-10.c: New test. >>> * c-c++-common/auto-init-11.c: New t

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

> On Sep 11, 2021, at 3:03 AM, Jakub Jelinek wrote: > > Note, the gcc.dg/i386/auto-init* tests fail also, just don't have time to > deal with that right now, just try > make check-gcc RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} > i386.exp=auto-init*' It’s strange that the above testing on

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

Hi, Jakub, > On Sep 16, 2021, at 4:19 AM, Jakub Jelinek wrote: > > On Wed, Sep 15, 2021 at 05:59:08PM +, Qing Zhao wrote: >>> Note, the gcc.dg/i386/auto-init* tests fail also, just don't have time to >>> deal with that right now, just try >>> make check-gcc RUNTESTFLAGS='--target_board=unix\

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

> On Sep 16, 2021, at 9:56 AM, Jakub Jelinek wrote: > > On Thu, Sep 16, 2021 at 02:49:23PM +, Qing Zhao wrote: >>> Testing for many instructions is always very fragile and dependent on exact >>> compiler flags etc. >> >> Yes, It’s indeed very fragile. >>> So, either the test should have a

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

> On Sep 16, 2021, at 10:47 AM, Jakub Jelinek wrote: > > On Thu, Sep 16, 2021 at 03:39:46PM +, Qing Zhao wrote: >>> Even -mtune= is needed if you want to stay safe, otherwise people testing >>> with --target_board=unix/-mtune=cascadelake (or whatever else) might get >>> failures. >> >> Ok

Re: [PATCH] testsuite: Fix c-c++-common/auto-init-* tests

> On Sep 16, 2021, at 12:39 PM, Iain Sandoe wrote: > > > >> On 16 Sep 2021, at 18:11, Qing Zhao via Gcc-patches >> wrote: >> >> >> >>> On Sep 16, 2021, at 10:47 AM, Jakub Jelinek wrote: >>> >>> On Thu, Sep 16, 2021

[PATCH] testsuite: Fix gcc.target/i386/auto-init-* tests.

Hi, This is the patch to fix gcc.target/i386/auto-init-* tests. I have tested the change at X86_64-linux with make check-gcc RUNTESTFLAGS='--target_board=unix\{-m64,-m64/-march=skylake-avx512,-m64/-fstack-protector-all,-m64/-fstack-clash-protection,-m32/-mno-sse,-m32/-mtune=bonnell,-m32/-march=

Re: [PATCH] testsuite: Fix gcc.target/i386/auto-init-* tests.

> On Sep 17, 2021, at 11:59 AM, Jakub Jelinek wrote: > > On Fri, Sep 17, 2021 at 04:55:22PM +, Qing Zhao wrote: >> This is the patch to fix gcc.target/i386/auto-init-* tests. >> >> I have tested the change at X86_64-linux with >> >> make check-gcc >> RUNTESTFLAGS='--target_board=unix\{-m

[HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

Hi, There are much less issues with aarch64/auto-init-* test cases. Different -march values (from ‘armv8-a’, ‘armv8.1-a’, till ‘armv8.6-a’, ‘armv8-r’) do not change the pattern match. Only 1. -mabi=ilp32/lp64 impact two of the testing cases “auto-init-2.c” and “auto-init-padding-5.c”. 2. -fst

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw > wrote: > > > > On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote: >> Hi, >> There are much less issues with aarch64/auto-init-* test cases. >> Different -march values (from ‘armv8-a’, ‘armv8.1-a’, til

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw > wrote: > > > > On 20/09/2021 13:47, Qing Zhao wrote: >>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw >>> wrote: >>> >>> >>> >>> On 17/09/2021 20:48, Qing Z

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

wrote: >>>>> On Sep 20, 2021, at 5:43 AM, Richard Earnshaw >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote: >>>>>> Hi, >>>>>

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

> On Sep 20, 2021, at 10:59 AM, Richard Earnshaw > wrote: > > > > On 20/09/2021 16:51, Qing Zhao via Gcc-patches wrote: >>> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw >>> wrote: >>> >>> >>> >>> On 20/09/2021 14:

Re: [HELP Needed!][PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.

M, Richard Earnshaw >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On 17/09/2021 20:48, Qing Zhao via Gcc-patches wrote: >>>>>> Hi, >>>>>> There are much less issues with aarch64/auto-init-* t

[PATCH][testsuite][aarch64]: Fix gcc.target/aarch64/auto-init-* tests.

Hi, This is the patch to fix gcc.target/aarch64/auto-init-* tests. I have tested the change on aarch64-linux with make check-gcc RUNTESTFLAGS='--target_board=unix\{-mabi=lp64,-mabi=ilp32,-mabi=lp64/-fstack-clash-protection/-fstack-protector-all,-mabi=ilp32/-fstack-clash-protection/-fstack-pro

Fwd: [PATCH][testsuite][aarch64]: Fix gcc.target/aarch64/auto-init-* tests.

Ping… Qing Begin forwarded message: From: Qing Zhao via Gcc-patches mailto:gcc-patches@gcc.gnu.org>> Subject: [PATCH][testsuite][aarch64]: Fix gcc.target/aarch64/auto-init-* tests. Date: September 21, 2021 at 2:20:58 PM CDT To: gcc-patches Nick Alcock via mailto:gcc-patches@gcc.g

[patch][gcc12-changes] Add a new item about the support for automatic static variable initialization

Hi, This is the patch for the gcc12 changes per your request. Kees provided most of the wording. Please take a look and let’s know whether it’s good for commit? thanks. Qing From: qing zhao Date: Tue, 28 Sep 2021 12:01:42 -0700 Subject: [

Re: [patch][gcc12-changes] Add a new item about the support for automatic static variable initialization

> On Sep 28, 2021, at 3:39 PM, Kees Cook wrote: > > On Tue, Sep 28, 2021 at 08:31:13PM +, Qing Zhao wrote: >> Hi, >> >> This is the patch for the gcc12 changes per your request. >> >> Kees provided most of the wording. >> >> Please take a look and let’s know whether it’s good for comm

Re: [patch][gcc12-changes] Add a new item about the support for automatic static variable initialization

> On Sep 29, 2021, at 5:39 AM, Richard Biener wrote: > > On Tue, 28 Sep 2021, Kees Cook wrote: > >> On Tue, Sep 28, 2021 at 08:31:13PM +, Qing Zhao wrote: >>> Hi, >>> >>> This is the patch for the gcc12 changes per your request. >>> >>> Kees provided most of the wording. >>> >>> Plea

Re: [patch][gcc12-changes] Add a new item about the support for automatic static variable initialization

FYI, just committed the change: https://gcc.gnu.org/gcc-12/changes.html Qing > On Sep 29, 2021, at 9:18 AM, Qing Zhao via Gcc-patches > wrote: > > > >> On Sep 29, 2021, at 5:39 AM, Richard Biener wrote: >> >> On Tue, 28 Sep 2021, Kees Cook wrote: >

[RFC][Patch][middle-end/PR102359]Not add initialization for READONLY variables with -ftrivial-auto-var-init

Hi, PR102359 (ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359 Is due to -ftrivial-auto-var-init adding initialization for READONLY variable “this” in the following routine: (t.cpp.005t.original) === ;; Function A::foo():: (nu

Re: [RFC][Patch][middle-end/PR102359]Not add initialization for READONLY variables with -ftrivial-auto-var-init

> On Sep 30, 2021, at 1:54 AM, Richard Biener wrote: > > On Thu, 30 Sep 2021, Jason Merrill wrote: > >> On 9/29/21 17:30, Qing Zhao wrote: >>> Hi, >>> >>> PR102359 (ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a) >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359 >>> >>> Is

Re: [RFC][Patch][middle-end/PR102359]Not add initialization for READONLY variables with -ftrivial-auto-var-init

> On Sep 30, 2021, at 1:54 AM, Richard Biener wrote: > > On Thu, 30 Sep 2021, Jason Merrill wrote: > >> On 9/29/21 17:30, Qing Zhao wrote: >>> Hi, >>> >>> PR102359 (ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a) >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359 >>> >>> Is

Re: [RFC][Patch][middle-end/PR102359]Not add initialization for READONLY variables with -ftrivial-auto-var-init

On Sep 30, 2021, at 1:54 AM, Richard Biener wrote: On Thu, 30 Sep 2021, Jason Merrill wrote: On 9/29/21 17:30, Qing Zhao wrote: Hi, PR102359 (ICE gimplification failed since r12-3433-ga25e0b5e6ac8a77a) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359 Is due to -ftrivial-auto-var-init add

Re: [Version 2][Patch][PR102281]do not add BUILTIN_CLEAR_PADDING for variables that are gimple registers

? Thanks. Qing > On Oct 25, 2021, at 9:16 AM, Qing Zhao via Gcc-patches > wrote: > > Ping…. > > Is this Okay for trunk? > >> On Oct 18, 2021, at 2:26 PM, Qing Zhao via Gcc-patches >> wrote: >> >> Hi, Jakub, >> >> T

Re: [Version 2][Patch][PR102281]do not add BUILTIN_CLEAR_PADDING for variables that are gimple registers

er there is any >> more issue with this version? Or it’s okay for commit now? > > I think it's reasonable. > > Thus OK unless Jakub has comments. > > Thanks, > Richard. > >> Thanks. >> >> Qing >> >> >> >>> On Oc

[patch][PR103033]handle the case when native_interpret_expr return NULL

Hi, PR103033 (c-c++-common/auto-init-4.c ICEs starting with r12-4829) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103033 Is an -ftrivial-auto-var-init bug exposed on Powerpc64-linux only. For the following code in gcc/internal-fn.c: 3085 if (can_native_interpret_type_p (var_typ

Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

Hi, I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11 and GCC12 (on the same X86 machine) For gcc11: wide int max elts =3 For gcc12: wide int max elts =9 Does anyone know what’s the reason for this difference? Thanks a lot for any help. Qing

Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

Thanks all for the information. Based on the information so far, my understanding is that we cannot revert r12-979-g782e57f2c09 Since it’s for enabling YMM and ZMM registers to be used for by_pieces operations on X86. Let me know if I miss anything here. FYI. This issue was found during my wo

Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

> On Nov 5, 2021, at 11:17 AM, Jakub Jelinek wrote: > > On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote: >> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE >> 3077 && tree_fits_uhwi_p (var_size) >> 3078 && (init_type == AUTO_INIT_PATTERN >> 3079

Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

Hi, I tried both the following patches: Patch1: [opc@qinzhao-ol8u3-x86 gcc]$ git diff diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c index 0cba95411a6..ca49d2b4514 100644 --- a/gcc/internal-fn.c +++ b/gcc/internal-fn.c @@ -3073,12 +3073,14 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)

Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

So, based on the discussion so far, is the following patch good to go? Let me know if you have more comments on the following patch: (At the same time, I am testing this patch on both x86 and aarch64) thanks. Qing diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c index 0cba95411a6..e8fd16b9c

Re: [PATCH v4 1/1] [ARM] Add support for TLS register based stack protector canary access

Hi, Ard, Sorry for the late reply (since I don’t have the right to approve a patch, I has been waiting for any arm port maintainer to review this patch). The following is the arm port maintainer information I got from MAINTAINERS file (you might want to explicitly cc’ing one of them for a review

Re: [PATCH v4 1/1] [ARM] Add support for TLS register based stack protector canary access

> On Nov 9, 2021, at 4:02 PM, Ard Biesheuvel wrote: > > On Tue, 9 Nov 2021 at 21:45, Qing Zhao wrote: >> >> Hi, Ard, >> >> Sorry for the late reply (since I don’t have the right to approve a patch, I >> has been waiting for any arm port maintainer to review this patch). >> The following is

Re: Values of WIDE_INT_MAX_ELTS in gcc11 and gcc12 are different

Pushed the patch as: https://gcc.gnu.org/pipermail/gcc-cvs/2021-November/356543.html Qing > On Nov 10, 2021, at 2:37 AM, Richard Biener > wrote: > > On Tue, Nov 9, 2021 at 6:48 PM Qing Zhao wrote: >> >> So, based on the discussion so far, is the following patch good to go? > > OK. > > T

<    1   2   3   4   5   6   7   8   >