> 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
>>> wr
> 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
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 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_SIZ
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
> 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
> 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 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 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
> 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
your 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 +++
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:
>
> 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
> 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.
>>
>>
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
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
rom 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 two cases.
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
> 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:
> 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 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, Q
> 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’,
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.
> 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
=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-protector
> 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, 20
> 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 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
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 check-g
s.
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 --
gcc/testsuite/gcc.target/i386/
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
;>> 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
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
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,
>
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 i
ceed.
>From b0034a941ff6a74589369a1f79cfc12295edf5d3 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Thu, 9 Sep 2021 15:00:26 +
Subject: [PATCH] doc/install.texi: add a generic advice on building gcc and
binutils together.
---
gcc/doc/install.texi | 10 --
1 file changed, 8 insertions
> 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,
>
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 wi
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 an
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,
> 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
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
> 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:
>>>
>>>
> 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
> 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
> 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
> 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
> 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
> 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:
>>>
>>
> 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
> 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:
>>>
>>>>
> 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:
>>
>> ==
> 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
> 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:
>>
>> ==
> 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:
>>
> 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
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
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) == SSA_N
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
mments 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:
>>>
>>> On Aug
> 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,
> 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
> 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
NIT 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 wrote:
>
>
> 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:
>>>
>>
> 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:
>>>
>>>
> 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
> 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,
>>>
>>>&g
> 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
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
> 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:
>>>
>>>
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)
>>>>> +{
>>>>> +
> 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
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
” 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 of the pa
> 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
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
uiltin_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.
>> 7. renam
> 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
> 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
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
> 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 worry ab
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 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, 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:
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
unctionality, 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, 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 f
021, 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:
>>>
> 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
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
(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
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
/*
Hi, Richard,
> On Jul 1, 2021, at 11:23 AM, Richard Sandiford
> wrote:
>
> Michael Matz writes:
>> Hello,
>>
>> On Thu, 1 Jul 2021, Richard Sandiford wrote:
>>
>>> Well, it does feel like this is pressing the reset button on a thread
>>> whose message count is already in the high double
Hi, Michael,
> On Jul 1, 2021, at 9:40 AM, Michael Matz wrote:
>
> Hello,
>
> I haven't followed this thread too closely, in particular I haven't seen
> why the current form of the .DEFERRED_INIT call was chosen or suggested,
> but it triggered my "well, that's obviously wrong" gut feeling;
> On Jul 1, 2021, at 9:09 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>>> On Jul 1, 2021, at 1:48 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
>>> wrote:
>>>>
> On Jul 1, 2021, at 9:04 AM, Richard Biener wrote:
>
> On Thu, Jul 1, 2021 at 3:45 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jul 1, 2021, at 1:48 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Jun 30, 2021 at 9:15 PM Qing Zha
> On Jul 1, 2021, at 1:48 AM, Richard Biener wrote:
>
> On Wed, Jun 30, 2021 at 9:15 PM Qing Zhao via Gcc-patches
> wrote:
>>
>>
>>
>>> On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
>>>
>>> On June 30, 2021 8:07:43 PM GMT+
701 - 800 of 1199 matches
Mail list logo
