;>> On Thu, Sep 09, 2021 at 10:49:11PM +, Qing Zhao wrote:
>>>> Hi, FYI
>>>>
>>>> I just committed the following patch to gcc upstream:
>>>>
>>>>
>>>> https://gcc.gnu.org/pipermail/gcc-cvs/2021-September/353195.html
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
d let me know your comments:
thanks.
Qing
From deb44a929ee27b097cc2351c4a4d7644bee68277 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Wed, 15 Sep 2021 17:22:07 +
Subject: [PATCH] fix i386 testing cases failure for m32
---
gcc/testsuite/gcc.target/i386/auto-init-2.c | 6 +++
Hi, Jakub,
> On Sep 16, 2021, at 4:19 AM, Jakub Jelinek wrote:
>
> On Wed, Sep 15, 2021 at 05:59:08PM +0000, 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 ch
> On Sep 16, 2021, at 9:56 AM, Jakub Jelinek wrote:
>
> On Thu, Sep 16, 2021 at 02:49:23PM +0000, Qing Zhao wrote:
>>> Testing for many instructions is always very fragile and dependent on exact
>>> compiler flags etc.
>>
>> Yes, It’s indeed very fragil
> On Sep 16, 2021, at 10:47 AM, Jakub Jelinek wrote:
>
> On Thu, Sep 16, 2021 at 03:39:46PM +0000, Qing Zhao wrote:
>>> Even -mtune= is needed if you want to stay safe, otherwise people testing
>>> with --target_board=unix/-mtune=cascadelake (or whatever e
> 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
for -march=x86-64 and -mtune=generic. Also
add -fno-stack-protector or -msse for some of the testing cases.
gcc/testsuite/ChangeLog:
2021-09-17 qing zhao
* gcc.target/i386/auto-init-1.c: Restrict the testing only for
-march=x86-64 and -mtune=generic. Add -fno-stack
> On Sep 17, 2021, at 11:59 AM, Jakub Jelinek wrote:
>
> On Fri, Sep 17, 2021 at 04:55:22PM +0000, 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-gc
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
> 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
> 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
> On Sep 20, 2021, at 9:36 AM, Richard Earnshaw
> wrote:
>
>
>
> On 20/09/2021 14:55, Qing Zhao wrote:
>>> On Sep 20, 2021, at 8:18 AM, Richard Earnshaw
>>> wrote:
>>>
>>>
>>>
>>> On 20/09/2021 13:47, Qing Zhao
> 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:
haw
> wrote:
>
>
>
> On 20/09/2021 14:55, Qing Zhao wrote:
>>> 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 A
=
>From c46888eed5621df842178a85adf7e221c7e00b48 Mon Sep 17 00:00:00 2001
From: qing zhao
Date: Tue, 21 Sep 2021 12:05:32 -0700
Subject: [PATCH] testsuite: Fix gcc.target/aarch64/auto-init-* tests.
Add -fno-stack-protector for two testing cases and also different
pattern match for lp64 and ilp32 for the other tw
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
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
> On Sep 28, 2021, at 3:39 PM, Kees Cook wrote:
>
> On Tue, Sep 28, 2021 at 08:31:13PM +0000, Qing Zhao wrote:
>> Hi,
>>
>> This is the patch for the gcc12 changes per your request.
>>
>> Kees provided most of the wording.
>>
>> Plea
> 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
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:
>
ur comments or suggestions on this.
Thanks a lot for the help.
Qing
==
From 0a5982cd61bc4610655d3df00ae8d2fbcb3c8e9b Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Wed, 29 Sep 2021 20:49:59 +
Subject: [PATCH] Fix PR102359
---
gcc/gimplify.c | 15 +++
> 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)
>>&g
> 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)
>>&g
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
?
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
Thank you.
I will commit this patch the beginning of next week.
Jakub, let me know if you have any objection on this.
Qing
> On Oct 29, 2021, at 2:21 AM, Richard Biener wrote:
>
> On Thu, 28 Oct 2021, Qing Zhao wrote:
>
>> Ping….
>>
>> Hi,
>>
>> B
the more conservative path to
generate “init”
The fix is very simple, and bootstrapped on x86, aarch64, and powerpc.
Regression testing are ongoing.
Okay for trunk?
Qing
=
From 22cf4fee8cf4b050ab41a3de074db70359421b23 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Tue, 2 Nov 2021 22:28:13 +
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
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
> On Nov 5, 2021, at 11:17 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 05, 2021 at 04:11:36PM +0000, Qing Zhao wrote:
>> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE
>> 3077 && tree_fits_uhwi_p (var_size)
>> 3078 &&a
ch 1 for the final patch to this issue.
Thanks.
Qing
> On Nov 8, 2021, at 2:41 AM, Richard Biener wrote:
>
> On Sat, Nov 6, 2021 at 10:56 AM Jakub Jelinek wrote:
>>
>> On Fri, Nov 05, 2021 at 05:37:25PM +, Qing Zhao wrote:
>>>> On Nov 5, 2021, at 11:17 A
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
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
> 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
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 p
Ping….
Qing
On May 12, 2021, at 12:16 PM, Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
Hi,
This is the 3rd version of the patch for the new security feature for GCC.
Please take look and let me know your comments and suggestions.
thanks.
Qing
**Compare wi
Hi, Richard,
Thanks a lot for your comments.
On May 26, 2021, at 6:18 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Wed, 12 May 2021, Qing Zhao wrote:
Hi,
This is the 3rd version of the patch for the new security feature for GCC.
Please take look and let me know your commen
(Resend, the previous version messed up your questions and my answers,
hopefully this time it’s better)
Hi, Richard,
Thanks a lot for your comments.
On May 26, 2021, at 6:18 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Wed, 12 May 2021, Qing Zhao wrote:
Hi,
This is t
Hi, Richard,
For the following, I need more clarification:
+/* Expand the IFN_DEFERRED_INIT function according to its second
argument. */
+static void
+expand_DEFERRED_INIT (internal_fn, gcall *stmt)
+{
+ tree var = gimple_call_lhs (stmt);
+ tree init = NULL_TREE;
+ enum auto_init_type init
Hi, Richard,
On May 26, 2021, at 6:18 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Wed, 12 May 2021, Qing Zhao wrote:
Hi,
This is the 3rd version of the patch for the new security feature for GCC.
Please take look and let me know your comments and suggestions.
+/* Return
(Kees, can you answer one of Richard’s question below? On the reason to
initialize padding of structures)
Richard,
On Jun 7, 2021, at 2:48 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
Meh - can you try using a mailer that does proper quoting? It's difficult
to spot your added comment
Hi,
> On Jun 7, 2021, at 2:53 AM, Richard Biener wrote:
>
>>
>> To address the above suggestion:
>>
>> My study shows: the call to __builtin_clear_padding is expanded during
>> gimplification phase.
>> And there is no __bultin_clear_padding expanding during rtx expanding phase.
>> However, f
On Jun 8, 2021, at 2:41 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
Which is also why I suggested to split out the padding initialization
bits to a separate patch (and option).
Personally, I am okay with splitting padding initialization from this current
patch,
Kees, what’s your op
, Richard Biener wrote:
>> On Mon, 7 Jun 2021, Qing Zhao wrote:
>>> On Jun 7, 2021, at 2:48 AM, Richard Biener
>>> mailto:rguent...@suse.de>> wrote:
>>>
>>> Meh - can you try using a mailer that does proper quoting? It's difficult
>>>
> On Jun 8, 2021, at 11:59 AM, Kees Cook wrote:
>
> On Tue, Jun 08, 2021 at 09:41:38AM +0200, Richard Biener wrote:
>> On Mon, 7 Jun 2021, Qing Zhao wrote:
>>>
>>> Personally, I am okay with splitting padding initialization from this
>>> current pa
Hi, Richard,
I need more discussion on the following comments you raised:
> On May 26, 2021, at 6:18 AM, Richard Biener wrote:
>
> +/* Expand the IFN_DEFERRED_INIT function according to its second
> argument. */
> +static void
> +expand_DEFERRED_INIT (internal_fn, gcall *stmt)
> +{
> + tree
> On Jun 11, 2021, at 6:12 AM, Richard Biener wrote:
>
> On Thu, 10 Jun 2021, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> I need more discussion on the following comments you raised:
>>
>>> On May 26, 2021, at 6:18 AM, Richard Biener wrote:
>&
On Jun 11, 2021, at 10:49 AM, Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On Jun 11, 2021, at 6:12 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Thu, 10 Jun 2021, Qing Zhao wrote:
Hi, Richard,
I need more discussion on the following comment
> On Sep 30, 2021, at 2:31 PM, Jason Merrill wrote:
>
> On 9/30/21 11:42, Qing Zhao wrote:
>>> 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 w
> On Oct 1, 2021, at 10:33 AM, Jason Merrill wrote:
>
> On 10/1/21 10:54, Qing Zhao wrote:
>>> On Sep 30, 2021, at 2:31 PM, Jason Merrill wrote:
>>>
>>> On 9/30/21 11:42, Qing Zhao wrote:
>>>>> On Sep 30, 2021, at 1:54 AM, Richard Bie
> On Oct 4, 2021, at 1:44 AM, Richard Biener wrote:
>
> On Fri, 1 Oct 2021, Qing Zhao wrote:
>
>>
>>
>>> On Oct 1, 2021, at 10:33 AM, Jason Merrill wrote:
>>>
>>> On 10/1/21 10:54, Qing Zhao wrote:
>>>>> On Sep 30, 202
I have several questions on this fix:
1. This fix avoided expanding “.DEFERRED_INIT” when !tree_fits_uhwi_p
(TYPE_SIZE_UNIT (var_type)).
As a result, this call to .DEFERRED_INIT will NOT be expanded at all.
Then not expanding .DEFERRED_INIT in RTL expanding phase will trigger more
issues
> On Oct 4, 2021, at 12:19 PM, Richard Biener wrote:
>
> On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao
> wrote:
>> I have several questions on this fix:
>>
>> 1. This fix avoided expanding “.DEFERRED_INIT” when !tree_fits_uhwi_p
>> (TYPE_SIZE_UNIT
001
From: qing zhao
Date: Mon, 4 Oct 2021 15:26:03 -0700
Subject: [PATCH] middle-end/102359 Not add initialization for variables that
have been initialized by FEs.
C++ FE creates proxy variables, which have associated DECL_VALUE_EXPR
and have been initialized by FE. For such auto variable,
> On Oct 5, 2021, at 3:19 AM, Richard Biener wrote:
>
> On Tue, 5 Oct 2021, Qing Zhao wrote:
>
>> Hi,
>>
>> This is the patch to fix this issue based on our discussion.
>>
>> I have tested it on aarch64 with bootstrap and regtests. X86 b
> On Oct 5, 2021, at 1:25 AM, Richard Biener wrote:
>
> On Mon, 4 Oct 2021, Qing Zhao wrote:
>
>>
>>
>>> On Oct 4, 2021, at 12:19 PM, Richard Biener wrote:
>>>
>>> On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao
>>> wrote:
&
This is the updated patch, I will push it after done with testing.
Let me know if you see any issue.
Thanks.
Qing.
>From 1f07c20ecdc9a015369c8bb472ebbd3bcaabdf17 Mon Sep 17 00:00:00 2001
From: qing zhao
Date: Tue, 5 Oct 2021 08:10:02 -0700
Subject: [PATCH] mid
> On Oct 5, 2021, at 1:30 PM, Jason Merrill wrote:
>
>>> 'decl_had_value_expr_p' and check && !decl_had_value_expr_p here?
>>> So sth like
>> I can do this -:) I agree that the change will make the code simpler.
>> However, my major concern with this change is: later when people look at
>> thi
ch is :
From cb2ef83e8f53c13694c70ac4bc1df6e09b15f1c7 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Tue, 12 Oct 2021 22:33:06 +
Subject: [PATCH] Fix pr102281
---
gcc/gimple-fold.c | 25 ++
gcc/gimple-fold.h | 1 +
gcc/gimplify.c
> On Oct 14, 2021, at 4:06 AM, Jakub Jelinek wrote:
>
> On Tue, Oct 12, 2021 at 10:51:45PM +0000, Qing Zhao wrote:
>> PR10228 1https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
>> Exposed an issue in the current implementation of the padding initialization
>>
On Oct 14, 2021, at 4:06 AM, Jakub Jelinek wrote:
On Tue, Oct 12, 2021 at 10:51:45PM +, Qing Zhao wrote:
PR10228 1https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
Exposed an issue in the current implementation of the padding initialization of
-ftrivial-auto-var-init.
Currently, we add
> On Oct 14, 2021, at 12:02 PM, Qing Zhao via Gcc-patches
> wrote:
>
>>
>> For !is_gimple_reg vars, yes, something like clear_padding_type_has_padding_p
>> could be useful to avoid unnecessary IL growth, but it should be implemented
>> more efficiently,
for trunk?
Thanks.
Qing.
=
>From ca78d82d7fe9064c0dcae845d1e4df34601fc083 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Sat, 16 Oct 2021 17:15:23 +
Subject: [PATCH] PR 102281 (-ftrivial-auto-var-init=zero causes ice)
Do not add call to __BUILTIN_CLEAR_PADDING w
> On Oct 18, 2021, at 10:36 AM, Jakub Jelinek wrote:
>
> On Mon, Oct 18, 2021 at 03:04:40PM +0000, Qing Zhao wrote:
>> 2021-10-16 qing zhao
>>
>> * gimplify.c (gimplify_decl_expr): Do not add call to
>> __BUILTIN_CLEAR_PADDING when a variable is a
> On Oct 18, 2021, at 11:46 AM, Jakub Jelinek wrote:
>
> On Mon, Oct 18, 2021 at 03:58:56PM +0000, Qing Zhao wrote:
>>> Furthermore, __builtin_clear_padding doesn't assume anything, but it takes
>>> an address of an object as argument and already th
> On Oct 18, 2021, at 12:15 PM, Jakub Jelinek wrote:
>
> On Mon, Oct 18, 2021 at 05:01:55PM +0000, Qing Zhao wrote:
>>> The where is typically somewhere in the FEs.
>>> But, there are two things.
>>> One is that in order to gimplify it properly, it needs to
Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Oct 2021 19:04:39 +
Subject: [PATCH] PR 102281 (-ftrivial-auto-var-init=zero causes ice)
Do not add call to __builtin_clear_padding when a variable is a gimple
register or it might not have padding.
gcc/ChangeLog:
2021-10-18 qing z
Hi,
In GCC, there are many utility routines for reporting error, warning, or
information, for example:
warning (0, "weak declaration of %q+D not supported", decl);
warning_at (stmtloc, OPT_Wmaybe_uninitialized, "%qE may be used
uninitialized", ptr));
inform (loc, "in a call to %qT declared wit
> On Oct 18, 2021, at 2:26 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi, Jakub,
>
> This is the 2nd version of the patch based on your comment.
>
> Bootstrapped on both x86 and aarch64. Regression testings are ongoing.
The regression testing was done. Looks go
Hi, Marek,
Thanks a lot for the information.
Really helpful.
Qing
> On Oct 20, 2021, at 12:57 PM, Marek Polacek wrote:
>
> On Wed, Oct 20, 2021 at 03:49:09PM +0000, Qing Zhao via Gcc-patches wrote:
>> Hi,
>>
>> In GCC, there are many utility routines for r
Ping….
Is this Okay for trunk?
> On Oct 18, 2021, at 2:26 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi, Jakub,
>
> This is the 2nd version of the patch based on your comment.
>
> Bootstrapped on both x86 and aarch64. Regression testings are ongoing.
The regre
Hi, Martin,
Thank you for the review and comment.
On Jul 8, 2021, at 8:29 AM, Martin Jambor
mailto:mjam...@suse.cz>> wrote:
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index c05d22f3e8f1..35051d7c6b96 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -384,6 +384,13 @@ static struct
/* Num
(Resend this email since the previous one didn’t quote, I changed one setting
in my mail client, hopefully that can fix this issue).
Hi, Martin,
Thank you for the review and comment.
> On Jul 8, 2021, at 8:29 AM, Martin Jambor wrote:
>> diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
>> index c05
Hi,
> On Jul 9, 2021, at 11:18 AM, Martin Jambor wrote:
>>
>>> On Jul 8, 2021, at 8:29 AM, Martin Jambor wrote:
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index c05d22f3e8f1..35051d7c6b96 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -384,6 +384,13 @@ static str
> On Jul 12, 2021, at 2:51 AM, Richard Sandiford
> wrote:
>
> Martin Jambor writes:
>> On Thu, Jul 08 2021, Qing Zhao wrote:
>>> (Resend this email since the previous one didn’t quote, I changed one
>>> setting in my mail client, hopefully that can
at 12:06 PM, Martin Jambor wrote:
>
> Hi,
>
> On Mon, Jul 12 2021, Qing Zhao wrote:
>>> On Jul 12, 2021, at 2:51 AM, Richard Sandiford
>>> wrote:
>>>
>>> Martin Jambor writes:
>>>> On Thu, Jul 08 2021, Qing Zhao wrote:
>>>
Hi, Kees,
Thanks a lot for your testing on kernel testing cases.
I have some question in below:
> On Jul 12, 2021, at 12:56 PM, Kees Cook wrote:
>
> On Wed, Jul 07, 2021 at 05:38:02PM +0000, Qing Zhao wrote:
>> Hi,
>>
>> This is the 4th version of the patch for t
but not with this patch.
Richard, what’s your comment and suggestions on this?
Thanks.
Qing
> On Jul 13, 2021, at 4:29 PM, Kees Cook wrote:
>
> On Mon, Jul 12, 2021 at 08:28:55PM +, Qing Zhao wrote:
>>> On Jul 12, 2021, at 12:56 PM, Kees Cook wrote:
>>> On Wed, Jul
Hi, Richard,
> On Jul 14, 2021, at 2:14 AM, Richard Biener
> wrote:
>
> On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote:
>>
>> Hi, Kees,
>>
>> I took a look at the kernel testing case you attached in the previous email,
>> and found
Hi, Kees,
> On Jul 14, 2021, at 2:11 PM, Kees Cook wrote:
>
> On Wed, Jul 14, 2021 at 02:09:50PM +0000, Qing Zhao wrote:
>> Hi, Richard,
>>
>>> On Jul 14, 2021, at 2:14 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jul 14, 2021 at 1:
> On Jul 14, 2021, at 4:23 PM, Kees Cook wrote:
>
> On Wed, Jul 14, 2021 at 07:30:45PM +0000, Qing Zhao wrote:
>> Hi, Kees,
>>
>>
>>> On Jul 14, 2021, at 2:11 PM, Kees Cook wrote:
>>>
>>> On Wed, Jul 14, 2021 at 02:09:50PM +, Qi
Hi, Richard,
> On Jul 15, 2021, at 2:56 AM, Richard Biener
> wrote:
>
>>> On Wed, Jul 14, 2021 at 1:17 AM Qing Zhao wrote:
>>>>
>>>> Hi, Kees,
>>>>
>>>> I took a look at the kernel testing case you attached in the previous
> On Jul 15, 2021, at 9:16 AM, Qing Zhao via Gcc-patches
> wrote:
>
>>
>>>>
>>>> Note that I think .DEFERRED_INIT can be elided for variables that do
>>>> not have their address
>>>> taken - otherwise we'll also have to wor
Hi,
After some more study on __builtin_clear_padding and the corresponding testing
cases.
And also considered both Richard Biener and Richard Sandiford’s previous
suggestion to use
__builtin_clear_padding. I have the following thought on the paddings
initialization:
** We can insert a ca
> On Jul 19, 2021, at 5:33 AM, Richard Biener wrote:
>
> On Fri, 16 Jul 2021, Qing Zhao wrote:
>
>> Hi,
>>
>> After some more study on __builtin_clear_padding and the corresponding
>> testing cases.
>> And also considered both Richard Biener and R
> On Jul 19, 2021, at 5:33 AM, Richard Biener wrote:
>
> On Fri, 16 Jul 2021, Qing Zhao wrote:
>
>> Hi,
>>
>> After some more study on __builtin_clear_padding and the corresponding
>> testing cases.
>> And also considered both Richard Biener and R
> On Jul 25, 2021, at 10:59 AM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi,
>
> This is the 5th 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 aarc
reuse __builtin_clear_padding for auto init purpose, add one
>> more dummy argument to indiciate whether it's for auto init or not,
>> if for auto init, do not emit error messages to avoid confusing users.
>> 6. Add new testing cases to verify padding initializations.
&g
Martin,
The following is the patch to fix the issues you raised in the previous email,
let me know if I still miss anything:
Thanks a lot.
Qing
=
From 14524a228b4b41b4eaaa2497455725e075126c2c Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 26 Jul 2021 15:46:59 +
Subject: [PATCH
> On Jul 26, 2021, at 11:09 AM, Martin Jambor wrote:
>
> Hi,
>
>>> So you either need to change build_access_from_expr like I described in
>>> my email
>>
>> Is the following the change you suggested previously:
>>
>> [opc@qinzhao-ol8u3-x86 gcc]$ git diff tree-sra.c
>> diff --git a/gcc/tree-
” is considered as an uninitialized usage.
I will move the call to __builtin_clear_padding after the variable
initialization.
Thanks.
Qing
> On Jul 28, 2021, at 3:21 PM, Kees Cook wrote:
>
> On Tue, Jul 27, 2021 at 03:26:00AM +0000, Qing Zhao wrote:
>> This is the 6th version o
e testsuite
> parts in the interests of time. I'll probably have more comments in
> future rounds, just wanted to get the ball rolling.
>
> This is realy Richi's area more than mine though, so please take this
> with a grain of salt.
>
> Qing Zhao writes:
>> 2.
Hi,
We met the following linking error when building our important application:
> …./ld: .o(.text.startup+0x13): unresolvable R_X86_64_TPOFF32 relocation
> against symbol `__gcov_indirect_call’
Looks like that current “__gcov_indirect_call”’s TLS_MODEL is local exec.
If recompiling .
> On Apr 26, 2021, at 12:47 PM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>>> @@ -1831,6 +2000,17 @@ gimplify_decl_expr (tree *stmt_p, gimple_seq *seq_p)
>>>> as they may contain a label address. */
>>>>
> On Apr 27, 2021, at 1:30 AM, Richard Biener wrote:
>
>>
>> equivalent in all respects. And if we were trying to make them
>> equivalent, we'd need to do much more than this.
>>
>> The same applies to the pattern case. If “x” is initialised to a pattern
>> that happens to point to a real
Hi, Richard,
During the change for the 2nd version based on your previous comments, I have
the following questions need your help:
>
>> + sra_stats.subtree_deferred_init++;
>> +}
>> + else if (access->grp_to_be_debug_replaced)
>> +{
>> + /* FIXME, this part might have so
>
>>
>>> @@ -11950,6 +12088,72 @@ lower_bound_in_type (tree outer, tree inner)
>>>}
>>> }
>>>
>>> +/* Returns true when the given TYPE has padding inside it.
>>> + return false otherwise. */
>>> +bool
>>> +type_has_padding (tree type)
>>
>> Would it be possible to reuse __builtin_clear_p
Richard,
Do you have any decision on this one?
Do we need this warning option For GCC?
thanks.
Qing
> On Dec 6, 2022, at 11:18 AM, Qing Zhao wrote:
>
> '-Wstrict-flex-arrays'
> Warn about inproper usages of flexible array members according to
> the LEVEL
> On Dec 14, 2022, at 4:03 AM, Richard Biener wrote:
>
> On Tue, 13 Dec 2022, Qing Zhao wrote:
>
>> Richard,
>>
>> Do you have any decision on this one?
>> Do we need this warning option For GCC?
>
> Looking at the testcases it seems t
1001 - 1100 of 1419 matches
Mail list logo
