> On Oct 4, 2022, at 1:37 PM, Joseph Myers wrote:
>
> On Tue, 4 Oct 2022, Qing Zhao via Gcc-patches wrote:
>
>> + { "strict_flex_array", 1, 1, false, false, false, false,
>> + handle_strict_flex_array_attribute, NULL },
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
hange has been Okayed by Bichard in the V3 of the
patch review. So, Joseph, could you please take a look at the FE and
doc changes and let me know whether they are good to commit?
thanks a lot.
Qing
Qing Zhao (2):
Add a new option -fstrict-flex-arrays[=n] and new attribute
strict_flex_a
Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_array to GCC:
'-fstrict-flex-arrays'
Control when to treat the trailing array of a structure as a flexible array
member for the purpose of accessing the elements of such an array.
The pos
> On Sep 30, 2022, at 1:39 PM, Martin Sebor wrote:
>
> On 9/28/22 13:17, Qing Zhao wrote:
>> Hi, Martin,
>> Thanks for the comments. And sorry for my late reply till now (I just came
>> back home from LPC, GNU Cauldron and then a one-week vacation after that…)
>&
Hi, Martin,
Thanks for the comments. And sorry for my late reply till now (I just came back
home from LPC, GNU Cauldron and then a one-week vacation after that…)
> On Sep 12, 2022, at 12:42 PM, Martin Sebor wrote:
>
> On 9/6/22 18:28, Qing Zhao wrote:
>> Add the following new
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
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
changes, and documentation format changes
recommanded by Joseph.
I have bootstrapped and regression tested on both aarch64 and x86, no issues.
Let me know if you have any comments on the patches.
thanks.
Qing Zhao (2):
Add a new option -fstrict-flex-arrays[=n] and new attribute
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 o
> 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
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
>&
> 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 s
> 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
> 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
> 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
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?
>>
.
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle.com>>
Subject: [[GCC13][Patch][V3] 1/2] Add a new option -fstrict-flex-array[=n] and
new attribute strict_flex_array
Date: August 17, 2022 at 10:40:41 AM EDT
To: gcc-patches@gcc.gnu.org<mailto:gcc-patches@gcc.gnu.org>
> 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'
>&
> 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 ab
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
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
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
> 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 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.
>>
>
> On Aug 11, 2022, at 3:40 AM, Richard Biener wrote:
>
> On Wed, 10 Aug 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> As mentioned in the bug report, I reopened this bug since the previous patch:
>>
>> commit r13-1875-gff26f0ba68fe6e870f315d0601b596f88
Hi,
As mentioned in the bug report, I reopened this bug since the previous patch:
commit r13-1875-gff26f0ba68fe6e870f315d0601b596f889b89680
Author: Richard Biener
Date: Thu Jul 28 10:07:32 2022 +0200
middle-end/106457 - improve array_at_struct_end_p for array objects
Array references
Never mind, just found how to do this:
/* { dg-warning "'-fstrict-flex-arrays' is not supported with a ISO C before
C99, ignored" "" { target *-*-* } 0 } */
And worked.
thanks.
Qing
> On Aug 3, 2022, at 2:52 PM, Qing Zhao via Gcc-patches
> wrote:
>
Hi,
My private cc1 issued the following warning:
[opc@qinzhao-ol8u3-x86 gcc]$ sh t
cc1: warning: ‘-fstrict-flex-arrays’ is not supported with a ISO C before C99,
ignored
I’d like to add a testing case for this warning into gcc.dg directory, however,
I cannot find a proper
testing directive to
> On Aug 2, 2022, at 12:34 PM, Marek Polacek wrote:
>
> On Tue, Aug 02, 2022 at 04:19:56PM +0000, Qing Zhao via Gcc-patches wrote:
>> Hi, Joseph,
>>
>> When -std=c89 or -std=gnu89 present in the command line, in C FE, which
>> flags should be
>> checke
Hi, Joseph,
When -std=c89 or -std=gnu89 present in the command line, in C FE, which flags
should be
checked to decide it’s -std=c89 or -std=gnu89?
Thanks a lot for your help.
Qing
Thanks a lot for your testing on Linux Kernel.
Will work on the version 3 of this patch soon.
Qing
> On Aug 2, 2022, at 11:30 AM, Kees Cook wrote:
>
> On Tue, Jul 19, 2022 at 02:11:19PM +0000, Qing Zhao wrote:
>> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:
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/tree-core.h
index ea9f281f1cc..458c6e6ceea 100644
--- a/gcc/tree-core.h
+++ b/gcc/tree-core.h
@@ -1813,7 +18
> On Aug 2, 2022, at 3:03 AM, Richard Biener wrote:
>
> On Mon, 1 Aug 2022, Qing Zhao wrote:
>
>>
>>
>>> On Aug 1, 2022, at 3:38 AM, Richard Biener wrote:
>>>
>>> On Fri, 29 Jul 2022, Qing Zhao wrote:
>>>
>>>> Hi,
> On Aug 1, 2022, at 3:38 AM, Richard Biener wrote:
>
> On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> Thanks a lot for your comments and suggestions. (And sorry for my late
>> reply).
>>
>>> On Jul 28, 2022, at 3:26 AM,
> On Aug 1, 2022, at 3:13 AM, Richard Biener wrote:
>
> On Fri, 29 Jul 2022, Qing Zhao wrote:
>
>>
>>
>>> On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
>>>
>>> On Tue, 19 Jul 2022, Qing Zhao wrote:
>>>
>>>>
Hi, Richard,
Thanks a lot for your comments and suggestions. (And sorry for my late reply).
> On Jul 28, 2022, at 3:26 AM, Richard Biener wrote:
>
> On Tue, 19 Jul 2022, Qing Zhao wrote:
>
>> From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001
>>
> On Jul 28, 2022, at 3:28 AM, Richard Biener wrote:
>
> On Tue, 19 Jul 2022, Qing Zhao wrote:
>
>> From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
>> From: Qing Zhao
>> Date: Mon, 18 Jul 2022 18:12:26 +
>> Subject: [PATCH 2/2
>From a09f39ded462611286a44d9e8273de8342673ba2 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Jul 2022 18:12:26 +
Subject: [PATCH 2/2] Use new flag DECL_NOT_FLEXARRAY in __builtin_object_size
[PR101836]
Use new flag DECL_NOT_FLEXARRAY to determine whether the trailing array
o
>From 3854004802b8e2f132ebf218fc35a632f5e80c6a Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 18 Jul 2022 17:04:12 +
Subject: [PATCH 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 correspond
Hi,
Based on the previous discussion on the Version 1 of the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597350.html
https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598010.html
We decided:
*User interface:
. command line option in C/C++:
-fstrict-flex-array[=N]
> On Jul 7, 2022, at 4:02 AM, Richard Biener wrote:
>
> On Wed, Jul 6, 2022 at 4:20 PM Qing Zhao wrote:
>>
>> (Sorry for the late reply, just came back from a short vacation.)
>>
>>> On Jul 4, 2022, at 2:49 AM, Richard Biener
>>> wrote:
>>
(Sorry for the late reply, just came back from a short vacation.)
> On Jul 4, 2022, at 2:49 AM, Richard Biener wrote:
>
> On Fri, Jul 1, 2022 at 5:32 PM Martin Sebor wrote:
>>
>> On 7/1/22 08:01, Qing Zhao wrote:
>>>
>>>
>>>> On Jul 1, 20
> On Jul 1, 2022, at 8:59 AM, Jakub Jelinek wrote:
>
> On Fri, Jul 01, 2022 at 12:55:08PM +0000, Qing Zhao wrote:
>> If so, comparing to the current implemenation to have all the checking in
>> middle-end, what’s the
>> major benefit of moving part of the checki
> On Jul 1, 2022, at 8:58 AM, Richard Biener wrote:
>
> On Fri, Jul 1, 2022 at 2:55 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jul 1, 2022, at 2:49 AM, Richard Biener
>>> wrote:
>>>
>>> On Thu, Jun 30, 2022 at 9:30 PM Qing Zhao wr
> On Jul 1, 2022, at 2:49 AM, Richard Biener wrote:
>
> On Thu, Jun 30, 2022 at 9:30 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jun 30, 2022, at 1:03 PM, Jakub Jelinek wrote:
>>>
>>> On Thu, Jun 30, 2022 at 03:31:00PM +, Qing Zhao w
> On Jun 30, 2022, at 1:03 PM, Jakub Jelinek wrote:
>
> On Thu, Jun 30, 2022 at 03:31:00PM +0000, Qing Zhao wrote:
>>> No, that’s not true. A FIELD_DELC is only shared for cv variants of a
>>> structure.
>>
>> Sorry for my dump questions:
>>
> On Jun 30, 2022, at 10:24 AM, Richard Biener
> wrote:
>
>
>
>> Am 30.06.2022 um 16:08 schrieb Qing Zhao via Gcc-patches
>> :
>>
>>
>>
>>> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote:
>>>
>>> On 6/28/22
> On Jun 29, 2022, at 5:14 PM, Martin Sebor wrote:
>
> On 6/28/22 13:01, Qing Zhao wrote:
>>> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote:
>>>
>>> On Tue, Jun 28, 2022 at 06:29:01PM +, Qing Zhao wrote:
>>>>
>>>&
Hi, Jakub and Joseph:
> On Jun 28, 2022, at 12:43 PM, Jakub Jelinek wrote:
>
> On Tue, Jun 28, 2022 at 03:59:22PM +0000, Qing Zhao via Gcc-patches wrote:
>>> On Jun 28, 2022, at 11:08 AM, Jakub Jelinek wrote:
>>>
>>> On Tue, Jun 28, 2022 at 03:03:12PM
> On Jun 28, 2022, at 2:49 PM, Jakub Jelinek wrote:
>
> On Tue, Jun 28, 2022 at 06:29:01PM +0000, Qing Zhao wrote:
>>
>>
>>> On Jun 28, 2022, at 2:22 PM, Jakub Jelinek wrote:
>>>
>>> On Tue, Jun 28, 2022 at 06:15:58PM +, Qing Zhao wrote
> On Jun 28, 2022, at 2:22 PM, Jakub Jelinek wrote:
>
> On Tue, Jun 28, 2022 at 06:15:58PM +0000, Qing Zhao wrote:
>>> Because the flag just tells whether some array shouldn't be treated as
>>> (poor man's)
>>> flexible array member. We still ne
> On Jun 28, 2022, at 12:43 PM, Jakub Jelinek wrote:
>
> On Tue, Jun 28, 2022 at 03:59:22PM +0000, Qing Zhao via Gcc-patches wrote:
>>> On Jun 28, 2022, at 11:08 AM, Jakub Jelinek wrote:
>>>
>>> On Tue, Jun 28, 2022 at 03:03:12PM +, Qing
> On Jun 28, 2022, at 11:08 AM, Jakub Jelinek wrote:
>
> On Tue, Jun 28, 2022 at 03:03:12PM +0000, Qing Zhao wrote:
>> 2. Then replace all “array_at_struct_end_p” with using DECL_NOT_FLEXARRAY in
>> GCC, adding new testing cases
>
> No, IMHO array_at_struct_end_p s
Hi, Richard,
> On Jun 28, 2022, at 3:16 AM, Richard Biener
> wrote:
>
> On Mon, Jun 27, 2022 at 4:20 PM Qing Zhao via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> Per our discussion in the bug report, I came up with the following patch:
>>
>>
Hi,
Per our discussion in the bug report, I came up with the following patch:
===
PR101836: Add a new option -fstrict-flex-array[=n]
Add the new option and use it in __builtin_object_size.
Treat the trailing array of a structure as a flexible array member in a
stricter way. The value of
Pushed to both gcc11 and gcc12.
thanks.
Qing
> On May 24, 2022, at 1:19 AM, Richard Biener wrote:
>
> On Mon, 23 May 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> I have added the patch to GCC11 and GCC12 in my local area and bootstrapped
>> and regress te
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
> 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 port
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 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:
>>>&g
> 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
>>
>> =
>>
>> Cu
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
> On Apr 21, 2022, at 2:09 AM, Richard Biener
> wrote:
>
> On Wed, Apr 20, 2022 at 6:02 PM Qing Zhao wrote:
>>
>>
>>
>>> On Apr 20, 2022, at 5:38 AM, Richard Biener
>>> wrote:
>>>
>>> On Tue, Apr 19, 2022 at 11:36 PM Qin
> On Apr 20, 2022, at 5:38 AM, Richard Biener
> wrote:
>
> On Tue, Apr 19, 2022 at 11:36 PM Qing Zhao wrote:
>>
>>
>>
>>> On Apr 14, 2022, at 1:53 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Apr 13, 2022 at 5:22 PM Qin
> On Apr 20, 2022, at 5:38 AM, Richard Biener
> wrote:
>
> On Tue, Apr 19, 2022 at 11:36 PM Qing Zhao wrote:
>>
>>
>>
>>> On Apr 14, 2022, at 1:53 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Apr 13, 2022 at 5:22 PM Qin
> On Apr 14, 2022, at 1:53 AM, Richard Biener
> wrote:
>
> On Wed, Apr 13, 2022 at 5:22 PM Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>> Thanks a lot for taking a look at this issue (and Sorry that I haven’t fixed
>> this one yet, I was distracte
Hi, Richard,
Thanks a lot for taking a look at this issue (and Sorry that I haven’t fixed
this one yet, I was distracted by other tasks then just forgot this one….)
> On Apr 13, 2022, at 3:41 AM, Richard Biener
> wrote:
>
> On Tue, Feb 15, 2022 at 5:31 PM Qing Zhao via Gcc-patc
FYI.
I have committed the change to upstream as:
31933f4f788b6cd64cbb7ee42076997f6d0fe212
Qing
> On Mar 31, 2022, at 8:10 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Hi,
>>
>> Per our discussion on:
>> https://gcc.gnu.org/pipermail/gcc-pat
Hi, Richard,
Thanks a lot for your reviewing on the non-x86 part.
Uros, could you please review the x86 part of the change?
thanks.
Qing
> On Mar 31, 2022, at 8:10 AM, Richard Sandiford
> wrote:
>
> Qing Zhao writes:
>> Hi,
>>
>> Per our discussion on:
&g
bootstrapped on both x86 and aarch64, no regression.
Okay for commit?
thanks.
Qing
===
From 2e5bc1b25a707c6a17afbf03da2a8bec5b03454d Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Fri, 18 Mar 2022 20:49:56 +
Subject: [PATCH] Add an assertion: the zeroed_hardregs set is
> On Mar 18, 2022, at 11:09 AM, Richard Sandiford
> wrote:
>
> Xi Ruoyao writes:
>>>
>>> If we have to go this way, I think it’s better to make the change you
>>> suggested above,
>>> and then also update the documentation, both internal documentation on
>>> how to define
>>> the hook and
> On Mar 14, 2022, at 11:04 AM, Richard Sandiford
> wrote:
>
> Sorry for the slow response, was out for a few days.
>
> Xi Ruoyao writes:
>> On Sat, 2022-03-12 at 18:48 +0800, Xi Ruoyao via Gcc-patches wrote:
>>> On Fri, 2022-03-11 at 21:26 +,
Thanks. Just committed the patch to gcc11 branch.
Qing
> On Mar 14, 2022, at 2:46 AM, Richard Biener
> wrote:
>
> On Fri, Mar 11, 2022 at 5:31 PM Qing Zhao via Gcc-patches
> wrote:
>>
>>
>> Hi,
>>
>> I plan to backport the patch to
will be helpful if you can provide more details on
what’ the root cause of the
Issue from your study into the comment part of the bug report.
> On Mar 11, 2022, at 11:29 AM, Xi Ruoyao wrote:
>
> On Fri, 2022-03-11 at 16:08 +0000, Qing Zhao wrote:
>
>> Why there is “mthi $0
regression.
Okay for commit?
thanks.
Qing.
==
>From 737a0b0824111f46da44c5578b9769070c52 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Thu, 10 Mar 2022 23:22:29 +
Subject: [PATCH] middle-end: updating the reg use in exit block for
-fzero-c
> On Mar 10, 2022, at 8:54 PM, Xi Ruoyao wrote:
>
> On Thu, 2022-03-10 at 20:31 +0000, Qing Zhao wrote:
>
>>>> + SET_HARD_REG_BIT (zeroed_hardregs, HI_REGNUM);
>>>> + if (TEST_HARD_REG_BIT (need_zeroed_hardregs, LO_REGNUM))
>>>> +
> On Mar 9, 2022, at 12:25 PM, Richard Sandiford via Gcc-patches
> wrote:
>
> Xi Ruoyao writes:
>> Bootstrapped and regtested on mips64el-linux-gnuabi64.
>>
>> I'm not sure if it's "correct" to clobber other registers during the
>> zeroing of scratch registers. But I can't really come up wi
as RHS
Bootstraped and regression tested on both x86 and aarch64.
Okay for committing?
thanks.
Qing.
From ca0193f48c8ae11719aa932db065bb24d4d649d7 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Mon, 28 Feb 2022 21:45:55 +
Subject: [PATCH] Don't emit s
both x86 and aarch64.
Okay for trunk?
Thanks.
Qing
=
>From 276975e60827942f0dd4043ce5f52e600327d6a8 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Thu, 24 Feb 2022 22:38:38 +
Subject: [PATCH] Suppress uninitialized warnings for new created uses from
__builtin_clear_pad
Hi,
After more study of all the discussion so far and the corresponding code for
suppress_warning, I think the following suggestion
Should be the best approach right now for this issue:
> SET_EXPR_LOCATION (tmp_dst, UNKNOWN_LOCATION);
> suppress_warning (tmp_dst, OPT_Wuninitialized)
> On Feb 25, 2022, at 6:43 AM, Richard Biener wrote:
>
> On Thu, 24 Feb 2022, Qing Zhao wrote:
>
>>
>>
>>> On Feb 24, 2022, at 4:16 AM, Richard Biener wrote:
>>>
>>> On Sat, 19 Feb 2022, Qing Zhao wrote:
>>>
&
> On Feb 25, 2022, at 2:38 AM, Richard Biener wrote:
>
> On Fri, 25 Feb 2022, Qing Zhao wrote:
>
>> Hi, Jakub and Richard:
>>
>> This is the 3rd version of the patch, the major change compared to the
>> previous version are:
>>
>> 1. Add w
on both x86 and aarch64.
Okay for trunk?
Thanks.
Qing
==
From 8314ded4ca0f59c5a3ec431c9c3768fcaf2a0949 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Thu, 24 Feb 2022 22:38:38 +
Subject: [PATCH] Suppress uninitialized warnings for new created uses from
I briefly checked all the usages of suppress_warning within the current gcc,
and see that most of them are not guarded by any condition.
So, the current change should be fine without introducing new issues. -:)
Another thing is, if we use “warning_enable_at” to guard, I just checked,
this rout
> On Feb 24, 2022, at 4:16 AM, Richard Biener wrote:
>
> On Sat, 19 Feb 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> This is the 2nd patch for fixing pr102276.
>>
>> Adding -Wtrivial-auto-var-init and update documentation.
>>
>> Adding a new
> On Feb 24, 2022, at 4:10 AM, Richard Biener wrote:
>
> On Sat, 19 Feb 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> Per our discussion in the bug report
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276
>>
>> We decided to go with the fol
==
>From a858be0fd979e05a6f54ac340e34bf85ddbc7067 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Wed, 23 Feb 2022 23:45:10 +
Subject: [PATCH] Suppress uninitialized warnings for new created uses from
__builtin_clear_padding folding [PR104550]
__builtin_clear_padding(&
> On Feb 24, 2022, at 2:46 AM, Richard Biener wrote:
>
> On Wed, 23 Feb 2022, Qing Zhao wrote:
>
>>
>>
>>> On Feb 23, 2022, at 11:49 AM, Jakub Jelinek wrote:
>>>
>>> On Wed, Feb 23, 2022 at 05:33:57PM +, Qing Zhao wrote:
>>&
Ping...
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: [PATCH 2/2][middle-end/102276] Adding -Wtrivial-auto-var-init and
update documentation.
Date: February 19, 2022 at 10:24:09 AM CST
To: richard Biener mailto:rguent...@s
Ping.
Qing
Begin forwarded message:
From: Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>>
Subject: [PATCH 1/2][middle-end/102276] Don't emit switch-unreachable warnings
for -ftrivial-auto-var-init (PR102276)
Date: February 19, 2022 at 10:22:43 AM CST
To: ric
> On Feb 23, 2022, at 11:49 AM, Jakub Jelinek wrote:
>
> On Wed, Feb 23, 2022 at 05:33:57PM +0000, Qing Zhao wrote:
>> From my understanding, __builtin_clear_padding (&object), does not _use_ any
>> variable,
>> therefore, no uninitialized usage w
Hi, Richard,
> On Feb 23, 2022, at 1:38 AM, Richard Biener wrote:
>
> On Tue, 22 Feb 2022, Qing Zhao wrote:
>
>> __builtin_clear_padding(&object) will clear all the padding bits of the
>> object.
>> actually, it doesn't involve any use of an user vari
ated uses from __builtin_clear_padding
folding.
The patch has been bootstrapped and regress tested on both x86 and aarch64.
Okay for trunk?
Thanks.
Qing
==
>From cf6620005f55d4a1f782332809445c270d22cf86 Mon Sep 17 00:00:00 2001
From: qing zhao
Date: Mon, 21 Feb 20
rom 4346890b8f4258489c4841f1992ba3ce816d7689 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Fri, 18 Feb 2022 15:53:15 +
Subject: [PATCH 2/2] 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 varia
.
===
>From 65bc9607ff35ad49e5501ec5c392293c5b6358d0 Mon Sep 17 00:00:00 2001
From: Qing Zhao
Date: Fri, 18 Feb 2022 15:35:53 +
Subject: [PATCH 1/2] Don't emit switch-unreachable warnings for
-ftrivial-auto-var-init (PR102276)
for the following testing case:
1 i
> 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
> 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,
> 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
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
601 - 700 of 1128 matches
Mail list logo
