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 comments and
(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 the 3rd versio
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.
+/* Returns true w
(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
Thanks a lot.
Kees.
Do you have the same issue with my emails?
I see this problem with my email mostly to part of the emails that were sent to
gcc-patches alias.
Other emails are fine.
> On Jun 8, 2021, at 11:56 AM, Kees Cook wrote:
>
> On Tue, Jun 08, 2021 at 09:37:30AM +0200, Richard Bi
> 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 patch,
>>> Kees, what’s your opinion on this? i
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:
>>>
>>> +/* Expand the IFN_DEFERRED_INIT function ac
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 wrote:
> Hi,
>
> PR102359 (ICE gimplification
> 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 Biener wrote:
>
> On Thu, 30 Sep 2021, Jason Merrill
> 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, 2021, at 2:31 PM, Jason Merrill wrote:
>
> On 9/30/21 11:42, Qing
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 (var_type)).
>> As a result, this ca
Hi,
This is the patch to fix this issue based on our discussion.
I have tested it on aarch64 with bootstrap and regtests. X86 bootstrap was
done, regtests is ongoing.
Okay for trunk?
Thanks.
Qing
==
>From d349ef0145512efe7f9af2c6bbd01f636475bce3 Mon Sep 17 00:00:00 2001
> 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 bootstrap was
>> done, regtests is ongoing.
>>
>> Oka
> 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:
I have several questions on this fix:
1. This
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] middle-
> 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
Hi,
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 __builtin_clear_padding call _AFTER_ every explicit
initialization of an auto variable:
var_decl = {init_c
> 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.
>>
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,
Hi,
PR102281 -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
Exposed multiple issues in the current padding clearing implementation of
-ftrivial-auto-var-init:
A. should check is_gimple_reg before adding the call to
__builtin_clear_padding; (corr
> On Oct 18, 2021, at 10:36 AM, Jakub Jelinek wrote:
>
> On Mon, Oct 18, 2021 at 03:04:40PM +, 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 gimple register
>
> The builtin
> On Oct 18, 2021, at 11:46 AM, Jakub Jelinek wrote:
>
> On Mon, Oct 18, 2021 at 03:58:56PM +, Qing Zhao wrote:
>>> Furthermore, __builtin_clear_padding doesn't assume anything, but it takes
>>> an address of an object as argument and already the taking of the address
>>> that gimple_add_pa
> On Oct 18, 2021, at 12:15 PM, Jakub Jelinek wrote:
>
> On Mon, Oct 18, 2021 at 05:01:55PM +, 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 be marked earlier.
>>> But the other
Hi, Jakub,
This is the 2nd version of the patch based on your comment.
Bootstrapped on both x86 and aarch64. Regression testings are ongoing.
Please let me know if this is ready for committing?
Thanks a lot.
Qing.
==
>From d6f60370dee69b5deb3d7ef51873a5e986490782 Mon Sep
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 fix this issue).
>>>
>>> Hi, Martin,
>>>
>
Hi, Martin,
Thanks a lot for your experiments and examples, they are really helpful.
So, based on your study, I will delete the code that handle
grp_to_be_debug_replaced accesses in generate_subtree_deferred_init.
Let me know if you have further comments on this.
Qing
> On Jul 12, 2021, at 1
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 +, Qing Zhao wrote:
>> Hi,
>>
>> This is the 4th version of the patch for the new security feature for
Hi, Kees,
I took a look at the kernel testing case you attached in the previous email,
and found the testing failed with the following case:
#define INIT_STRUCT_static_all = { .one = arg->one,\
.two = arg->two,\
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 the testing failed with the following case:
>>
>> #define
Hi, Kees,
> On Jul 14, 2021, at 2:11 PM, Kees Cook wrote:
>
> On Wed, Jul 14, 2021 at 02:09:50PM +, Qing Zhao wrote:
>> 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
> On Jul 14, 2021, at 4:23 PM, Kees Cook wrote:
>
> On Wed, Jul 14, 2021 at 07:30:45PM +, 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 +, Qing Zhao wrote:
Hi, Richard,
> On Jul 14, 202
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
email, and found the testing failed with the following case:
>>
> 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 Richard Sandiford’s previous
>> suggestion t
> 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 Richard Sandiford’s previous
>> suggestion t
> 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
HI, Martin,
Thank you for the comments and suggestions on tree-sra.c changes.
>> **Compare with the 4th version, the following are the major changes:
>>
>> 1. delete the code for handling "grp_to_be_debug_replaced" since they are
>> not needed per Martin Jambor's suggestion.
>
> sorry if I
red_init++;
+ gcc_assert (!lhs_access->first_child);
+ return SRA_AM_MODIFIED;
}
if (lhs_access->first_child)
--
2.27.0
> On Jul 26, 2021, at 10:25 AM, Qing Zhao via Gcc-patches
> wrote:
>
> HI, Martin,
>
> Thank you for the comments and suggestion
> 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-
Hi, Kees,
Thanks a lot for your testing and the small testing case.
I just studied the root cause of this bug, and found that it’s because the call
to “__builtin_clear_padding()” should NOT be inserted BEFORE
the variable initialization. It should be inserted AFTER the variable
initialization.
Hi, Richard,
Thanks a lot for your review.
> On Apr 23, 2021, at 2:05 PM, Richard Sandiford
> wrote:
>
> Finally getting to this now that the GCC 11 rush is over. Sorry for
> the slow response.
>
> I've tried to review most of the code below, but skipped the testsuite
> parts in the interest
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. */
walk_tree (&init, force_labels_r, NULL, NULL);
}
> 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 of the 'strict_flex_array (
> 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 that the diagnostic amends
> -Warray-bounds diagnostics
> On Dec 14, 2022, at 9:08 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Dec 14, 2022, at 4:03 AM, Richard Biener wrote:
>>
>> On Tue, 13 Dec 2022, Qing Zhao wrote:
>>
>>> Richard,
>>>
>>> Do you have any
Hi, Richard,
I guess that we now agreed on the following:
“ the information that we ran into a trailing array but didn't consider
it a flex array because of -fstrict-flex-arrays is always a useful information”
The only thing we didn’t decide is:
A. Amend such new information to -Warray-bounds
> On Dec 15, 2022, at 2:47 AM, Richard Biener wrote:
>
> On Wed, 14 Dec 2022, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> I guess that we now agreed on the following:
>>
>> “ the information that we ran into a trailing array but didn't consider
>> it a flex array because of -fstrict-flex-array
> On Dec 16, 2022, at 4:17 AM, Richard Biener wrote:
>
> On Thu, 15 Dec 2022, Qing Zhao wrote:
>
>>
>>
>>> On Dec 15, 2022, at 2:47 AM, Richard Biener wrote:
>>>
>>> On Wed, 14 Dec 2022, Qing Zhao wrote:
>>>
Hi, Richard,
I guess that we now agreed on the following:
>
FYI.
Committed this last patch as:
https://jira.oci.oraclecorp.com/browse/OLDIS-21095
I will come up with the update to gcc-13/changes.html for -fstrict-flex-arrays
very soon.
Thanks.
Qing
> On Dec 16, 2022, at 9:49 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On
Hi,
This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2
changes in gcc-13/changes.html.
Let me know if you have any comment or suggestions.
Thanks.
Qing.
===
>From c022076169b4f1990b91f7daf4cc52c6c5535228 Mon Sep 17 00:00:00 2001
From
Hi, Richard,
Thanks a lot for your comments.
> On Dec 21, 2022, at 2:12 AM, Richard Biener wrote:
>
> On Tue, 20 Dec 2022, Qing Zhao wrote:
>
>> Hi,
>>
>> This is the patch for mentioning -fstrict-flex-arrays and -Warray-bounds=2
>> changes in gcc-13/changes.html.
>>
>> Let me know if you h
> On Dec 22, 2022, at 2:09 AM, Richard Biener wrote:
>
> On Wed, 21 Dec 2022, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> Thanks a lot for your comments.
>>
>>> On Dec 21, 2022, at 2:12 AM, Richard Biener wrote:
>>>
>>> On Tue, 20 Dec 2022, Qing Zhao wrote:
>>>
Hi,
This is th
> On Dec 22, 2022, at 12:56 PM, Alexander Monakov wrote:
>
>
> On Thu, 22 Dec 2022, Jose E. Marchesi via Gcc-patches wrote:
>
>> The first instruction scheduler pass reorders instructions in the TRY
>> block in a way `b=true' gets executed before the call to the function
>> `f'. This optimi
> On Dec 23, 2022, at 2:33 AM, Alexander Monakov wrote:
>
>
> On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>>> I think scheduling across calls in the pre-RA scheduler is simply an
>>> oversight,
>>> we do not look at dataflow information and with 50% chance risk extending
>>> lifetime of a pseudo
Then, sched2 still can move insn across calls?
So does sched2 have the same issue of incorrectly moving the insn across a
call which has unknown control flow?
Qing
> On Dec 23, 2022, at 12:31 PM, Alexander Monakov wrote:
>
>
> On Fri, 23 Dec 2022, Jose E. Marchesi wrote:
>
>>> (scheduling
> On Dec 23, 2022, at 2:36 PM, Alexander Monakov wrote:
>
>
>
> On Fri, 23 Dec 2022, Qing Zhao wrote:
>
>> Then, sched2 still can move insn across calls?
>> So does sched2 have the same issue of incorrectly moving the insn across a
>> call which has unknown control flow?
>
> I think pro
Alexander,
(Sorry for the late reply due to holiday vacation).
> On Dec 24, 2022, at 3:10 AM, Alexander Monakov wrote:
>
>
> On Fri, 23 Dec 2022, Qing Zhao wrote:
>
>> BTW, Why sched1 is not enabled on x86 by default?
>
> Register allocation is tricky on x86 due to small number of general-pu
> On Jan 9, 2023, at 2:11 AM, Richard Biener wrote:
>
> On Thu, 22 Dec 2022, Qing Zhao wrote:
>
>>
>>
>>> On Dec 22, 2022, at 2:09 AM, Richard Biener wrote:
>>>
>>> On Wed, 21 Dec 2022, Qing Zhao wrote:
>>>
Hi, Richard,
Thanks a lot for your comments.
> On Dec 21
> On Jan 10, 2023, at 3:06 AM, Richard Biener wrote:
>
> On Mon, 9 Jan 2023, Qing Zhao wrote:
>
>>
>>
>>> On Jan 9, 2023, at 2:11 AM, Richard Biener wrote:
>>>
>>> On Thu, 22 Dec 2022, Qing Zhao wrote:
>>>
> On Dec 22, 2022, at 2:09 AM, Richard Biener wrote:
>
>
We should not directly check flag_strict_flex_arrays in the middle end.
Instead, check DECL_NOT_FLEXARRAY(array_field_decl) which is set by
C/C++ FEs according to -fstrict-flex-arrays and the corresponding attribute
attached to the array_field.
As a result, We will lose the LEVEL information of -f
this is the patch to replace all references to flag_strict_flex_arrays
with DECL_NOT_FLEXARRAY in middle-end per the discussion.
I have bootstrapped and regression tested on X86, no issues.
Okay for commit?
thanks.
Qing
ld Pfeifer wrote:
>
> On Tue, 20 Dec 2022, Qing Zhao via Gcc-patches wrote:
>> +Treating trailing arrays as flexible array
>> members
>
> Please note that ids must not contain white space.
>
> Would you mind following up making this "flexiblearray" or similiar?
>
> Thank you,
> Gerald
> On Aug 18, 2023, at 12:00 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Aug 17, 2023, at 5:32 PM, Siddhesh Poyarekar wrote:
>>
>> On 2023-08-17 17:25, Qing Zhao wrote:
>>>> It's not exactly the same issue, the earlier discussion was
Provide a new counted_by attribute to flexible array member field.
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the flexible array
member of a structure. It indicates that the number of the
elements of the array is given by the field named "COUNT" in the
This is the 3rd version of the patch, per our discussion based on the
review comments for the 1st and 2nd version, the major changes in this
version are:
***Against 1st version:
1. change the name "element_count" to "counted_by";
2. change the parameter for the attribute from a STRING to an
Identi
Use the counted_by atribute info in builtin object size to compute the
subobject size for flexible array members.
gcc/ChangeLog:
PR C/108896
* tree-object-size.cc (addr_object_size): Use the counted_by
attribute info.
* tree.cc (component_ref_has_counted_by_p): New
Use the counted_by attribute information in bound sanitizer.
gcc/c-family/ChangeLog:
PR C/108896
* c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute
information.
gcc/testsuite/ChangeLog:
PR C/108896
* gcc.dg/ubsan/flex-array-counted-by-bounds
> On Aug 29, 2023, at 3:42 PM, Marek Polacek via Gcc-patches
> wrote:
>
> Improving the security of software has been a major trend in the recent
> years. Fortunately, GCC offers a wide variety of flags that enable extra
> hardening. These flags aren't enabled by default, though. And since
Ping.
Thanks.
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> This is the 3rd version of the patch, per our discussion based on the
> review comments for the 1st and 2nd version, the major changes in this
> version are:
>
> ***Against 1st version:
> 1. change the name "element_cou
PIng.
thanks.
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> Provide a new counted_by attribute to flexible array member field.
>
> 'counted_by (COUNT)'
> The 'counted_by' attribute may be attached to the flexible array
> member of a structure. It indicates that the number
Ping.
thanks.
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> Use the counted_by attribute information in bound sanitizer.
>
> gcc/c-family/ChangeLog:
>
> PR C/108896
> * c-ubsan.cc (ubsan_instrument_bounds): Use counted_by attribute
> information.
>
> gcc/testsu
Ping.
thanks.
Qing
> On Aug 25, 2023, at 11:24 AM, Qing Zhao wrote:
>
> Use the counted_by atribute info in builtin object size to compute the
> subobject size for flexible array members.
>
> gcc/ChangeLog:
>
> PR C/108896
> * tree-object-size.cc (addr_object_size): Use the count
on conflict across an abnormal edge
This is a bug in tree-ssa-math-opts.cc, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.
bootstrapped and regression tested on both aarch64 and x86, no
Hi,
I have several questions on these options:
1.are pointers treated as signed integers in general? (I thought that pointers
are addresses to the memory, should be treated as unsigned integer…)
2. If Yes, why?
3. why a separate option for pointesr -fwrapv-pointer in addition to -fwrapv if
the
Thanks for the info.
> On Sep 14, 2023, at 10:06 AM, Richard Biener
> wrote:
>
> On Thu, Sep 14, 2023 at 3:42 PM Qing Zhao via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> I have several questions on these options:
>>
>> 1.are pointers tre
> On Sep 14, 2023, at 11:12 AM, Richard Biener
> wrote:
>
>
>
>> Am 14.09.2023 um 17:01 schrieb Qing Zhao :
>>
>> Thanks for the info.
>>
>>> On Sep 14, 2023, at 10:06 AM, Richard Biener
>>> wrote:
>>>
>>
> On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote:
>
> On Thu, 2023-09-14 at 15:57 +0000, Qing Zhao via Gcc-patches wrote:
>> Currently, GCC behaves as following:
>>
>> /* True if overflow wraps around for the given integral or pointer type.
>> That
&
> On Sep 14, 2023, at 4:57 PM, Andrew Pinski wrote:
>
> On Thu, Sep 14, 2023 at 1:50 PM Qing Zhao via Gcc-patches
> wrote:
>>
>>
>>
>>> On Sep 14, 2023, at 12:18 PM, Xi Ruoyao wrote:
>>>
>>> On Thu, 2023-09-14 at 15:57 +, Qin
thanks.
Committed as https://gcc.gnu.org/pipermail/gcc-cvs/2023-September/389614.html
Qing
> On Sep 15, 2023, at 2:12 AM, Richard Biener
> wrote:
>
> On Thu, Sep 14, 2023 at 3:25 PM Qing Zhao via Gcc-patches
> wrote:
>>
>> on conflict across an abnormal edge
>&
> On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote:
>
> On Thu, 2023-09-14 at 21:41 +, Qing Zhao wrote:
CLANG already provided -fsanitize=unsigned-integer-overflow. GCC
might need to do the same.
>>>
>>> NO. There is no such thing as unsigned integer overflow. That option
>>> is badl
401 - 500 of 783 matches
Mail list logo
