I found a bug with this patch, will fix it and send out the updated patch.
Please ignore this one.
sorry.
Qing
> On Feb 6, 2023, at 8:47 AM, Qing Zhao wrote:
>
> This is the 2nd version of the patch, compare to the first version, the major
> changes are:
>
> 1. A
> On Feb 8, 2023, at 2:20 PM, Siddhesh Poyarekar wrote:
>
> On 2023-02-08 14:09, Joseph Myers wrote:
>> What must be avoided is -pedantic diagnostics for
>> struct flex1 { int n; int data[1]; };
>> struct out_flex_end1 { int m; struct flex1 flex_data; };
>> regardless of whether considered fle
> On Feb 8, 2023, at 2:09 PM, Joseph Myers wrote:
>
> On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
>
>> But I noticed that “flexible_array_type_p” later was moved from FE to
>> middle-end and put into tree.cc, tree.h as a general utility routine, and to
>
> On Feb 9, 2023, at 5:35 AM, Richard Biener wrote:
>
> On Wed, 8 Feb 2023, Qing Zhao wrote:
>
>>
>>
>>> On Feb 7, 2023, at 6:37 PM, Joseph Myers wrote:
>>>
>>> On Tue, 7 Feb 2023, Qing Zhao via Gcc-patches wrote:
>>>
&
> On Feb 8, 2023, at 6:18 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Feb 8, 2023, at 2:09 PM, Joseph Myers wrote:
>>
>> On Wed, 8 Feb 2023, Qing Zhao via Gcc-patches wrote:
>>
>>> But I noticed that “flexible_array_type_p” later
Thanks, Kees.
If there is no objection, I will update my patches with this. And send the
updated patches soon.
Qing
> On Feb 9, 2023, at 11:46 AM, Kees Cook wrote:
>
> On Thu, Feb 09, 2023 at 02:40:57PM +0000, Qing Zhao wrote:
>> So, the major question here is:
>>
>
GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-decl.cc (finish_struct):
on structure with C99 flexible array member being nested in another structure.
This is also fixed PR77650.
" GCC extension accepts a structure containing a ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are thr
These are the 3rd version of the patches for PR101832, to fix
builtin_object_size to correctly handle component_ref to a
structure/union field that includes a flexible array member.
also includes a documentation update for the GCC extension on embedding
a structure/union with flexible array member
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
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:
>>
>>
> 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
> 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 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 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
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
ote:
>
> On Thu, Feb 25, 2021 at 05:56:38PM -0600, Qing Zhao wrote:
>> Just noticed that you didn’t add -fauto-var-init-approach=D to the command
>> line.
>
> Ah-ha! I didn't realize that was needed; thanks. However, now some of the
> sources crash in a different way
> On Mar 11, 2021, at 6:46 PM, Kees Cook wrote:
>
> On Thu, Mar 11, 2021 at 03:47:17PM -0600, Qing Zhao wrote:
>> Hi, Kees,
>>
>> Sorry for the late reply (I have been busy with other work recently).
>>
>> Currently, I am working on the issue of flex
Hi, Kees,
I am looking at the structure padding initialization issue. And also have some
questions:
> On Feb 24, 2021, at 10:41 PM, Kees Cook wrote:
>
> It looks like there is still some issues with padding and pre-case
> switch variables. Here's the test output, FWIW:
>
>
> test_stackinit:
(CC’ing gcc-patch alias).
Hi, Kees,
> On Mar 12, 2021, at 3:55 PM, Kees Cook wrote:
>
> On Fri, Mar 12, 2021 at 03:35:28PM -0600, Qing Zhao wrote:
>> Hi, Kees,
>>
>> I am looking at the structure padding initialization issue. And also have
>> some questions
Yes, basically, I agreed with Eric.
One of the major reason to intentionally put these testing cases under
c-c++-common
is to fail them by default on the platforms that do not support this feature
yet.
Then the platform maintainer could decide whether to complete this feature on
the
specif
Ping
> On Mar 24, 2021, at 4:21 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi,
>
> This is the 2nd version of the patch for the new security feature for GCC.
>
> Could you please take a look at it and let me know any comments and issues.
>
> Thanks.
>
>
Hi, Kees,
Thanks a lot for your testing on the linux kernel, I am so happy that this time
it works well.
> On Apr 7, 2021, at 5:19 PM, Kees Cook wrote:
>
> On Wed, Mar 24, 2021 at 04:21:49PM -0500, Qing Zhao wrote:
>> This is the 2nd version of the patch for the new security
Hi, Richard:
On Jun 11, 2021, at 10:49 AM, Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
On May 26, 2021, at 6:18 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
+/* Expand the IFN_DEFERRED_INIT function according to its second
argument. */
Hi, Richard,
> On Jun 15, 2021, at 8:21 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 var = gimple_call_lhs (stmt);
>> + tree init = NUL
Hi, Richard,
On Jun 16, 2021, at 1:19 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
+/* 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_TR
So, the major question now is:
Is one single repeatable pattern enough for pattern initialization for all
different types of auto variables?
If YES, then the implementation for pattern initialization will be much easier
and simpler
as you pointed out. And will save me a lot of pain to imp
HI, Richard,
> On Jun 21, 2021, at 2:53 AM, Richard Biener wrote:
>
>>
>>
>> This is for the compatibility with CLANG. -:).
>> (https://reviews.llvm.org/D54604)
>
> I don't care about functional 1:1 "compatibility" with CLANG.
Okay. -:)
>
>> 1. Pattern initialization
>>
>> This is the
Hi, Kees,
On Jun 18, 2021, at 6:47 PM, Kees cook
mailto:keesc...@chromium.org>> wrote:
On Wed, Jun 16, 2021 at 07:39:02PM +, Qing Zhao wrote:
So, the major question now is:
Is one single repeatable pattern enough for pattern initialization for all
different types of auto variable
> On Jun 21, 2021, at 10:35 AM, Richard Biener wrote:
>>> I think we can drop -fauto-var-init=pattern and just go with block
>>> initializing which will cover padding as well which means we can
>>> stay with the odd -ftrivial-auto-var-init name used by CLANG and
>>> add no additional options.
>>
> On Jun 21, 2021, at 11:18 AM, Kees Cook wrote:
>
> On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote:
>> So, if “pattern value” is “0x”, then it’s a valid canonical
>> virtual memory address. However, for most OS, “0x” should
&g
ichard Sandiford wrote:
Kees Cook mailto:keesc...@chromium.org>> writes:
On Mon, Jun 21, 2021 at 03:39:45PM +0000, Qing Zhao wrote:
So, if “pattern value” is “0x”, then it’s a valid canonical
virtual memory address. However, for most OS, “0x” should be
not i
> On Jun 22, 2021, at 9:00 AM, Richard Biener wrote:
>
> On Tue, 22 Jun 2021, Qing Zhao wrote:
>
>> So, I am wondering why not still keep my current implementation on
>> assign different patterns for different types?
>>
>> This major issue with this
> On Jun 22, 2021, at 9:15 AM, Richard Biener wrote:
>
> On Tue, 22 Jun 2021, Qing Zhao wrote:
>
>>
>>
>>> On Jun 22, 2021, at 9:00 AM, Richard Biener wrote:
>>>
>>> On Tue, 22 Jun 2021, Qing Zhao wrote:
>>>
>>>
22, 2021 at 09:25:57AM +0100, Richard Sandiford wrote:
>>> Kees Cook writes:
>>>> On Mon, Jun 21, 2021 at 03:39:45PM +, Qing Zhao wrote:
>>>>> So, if “pattern value” is “0x”, then it’s a valid
>>>>> canonical virtual memory
Hi,
I am testing the 4th patch of -ftrivial-auto-var-init with CPU2017 today, and
found the following issues:
In the dump file of “*t.i.031t.objsz1”, we have:
:
__s1_len_217 = .DEFERRED_INIT (__s1_len_176, 2);
__s2_len_218 = .DEFERRED_INIT (__s2_len_177, 2);
__s2_len_219 = 7;
if (
On Jun 30, 2021, at 2:46 AM, Richard Biener
mailto:rguent...@suse.de>> wrote:
On Wed, 30 Jun 2021, Qing Zhao wrote:
Hi,
I am testing the 4th patch of -ftrivial-auto-var-init with CPU2017 today, and
found the following issues:
In the dump file of “*t.i.031t.objsz1”, w
> On Jun 30, 2021, at 9:39 AM, Richard Biener wrote:
>
> On Wed, 30 Jun 2021, Qing Zhao wrote:
>
>>
>>
>> On Jun 30, 2021, at 2:46 AM, Richard Biener
>> mailto:rguent...@suse.de>> wrote:
>>
>> On Wed, 30 Jun 2021, Qing Zhao wrote:
>
bug ?
Qing
> On Jun 30, 2021, at 9:39 AM, Richard Biener wrote:
>
> On Wed, 30 Jun 2021, Qing Zhao wrote:
>
>>
>>
>> On Jun 30, 2021, at 2:46 AM, Richard Biener
>> mailto:rguent...@suse.de>> wrote:
>>
>> On Wed, 30 Jun 2021, Qing Zhao wro
Hi, Andrew,
Thanks a lot for your explanation.
On Jun 30, 2021, at 12:20 PM, Andrew Pinski
mailto:pins...@gmail.com>> wrote:
On Wed, Jun 30, 2021 at 8:47 AM Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wrote:
I came up with a very simple testing case that can rep
> On Jun 30, 2021, at 12:36 PM, Richard Biener wrote:
>
> On June 30, 2021 7:20:18 PM GMT+02:00, Andrew Pinski
> wrote:
>> On Wed, Jun 30, 2021 at 8:47 AM Qing Zhao via Gcc-patches
>> wrote:
>>>
>>> I came up with a very simple test
<0(2), i_15(3)>
if (i_2 < a_9(D))
goto ; [INV]
else
goto ; [INV]
:
return;
}
The constant “4” is propagated to the call to “ART_INIT”.
This looks incorrect. Right?
Qing
On Jun 30, 2021, at 1:07 PM, Qing Zhao via Gcc-patches
mailto:gcc-patches@gcc.gnu.org>> wr
> On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
>
> On June 30, 2021 8:07:43 PM GMT+02:00, Qing Zhao wrote:
>>
>>
>>> On Jun 30, 2021, at 12:36 PM, Richard Biener
>> wrote:
>>>
>>> On June 30, 2021 7:20:18 PM GMT+02:00, Andrew
> On Jun 30, 2021, at 1:59 PM, Richard Biener wrote:
>
> On June 30, 2021 8:07:43 PM GMT+02:00, Qing Zhao wrote:
>>
>>
>>> On Jun 30, 2021, at 12:36 PM, Richard Biener
>> wrote:
>>>
>>> On June 30, 2021 7:20:18 PM GMT+02:00, Andrew
Hi, Andrew:
> On Jun 30, 2021, at 2:20 PM, Andrew Pinski wrote:
>
Then, where is the correct place for “.DEFERRED_INIT(size2,2)?
The variable “size2” is a block scope variable which is declared inside
the “if” condition:
>>>
>>> But that's obviously not how it beh
> 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+
> 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 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:
>>>>
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; s
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 figu
AM, Richard Biener wrote:
>
> On Tue, 8 Nov 2022, Qing Zhao wrote:
>
>> '-Wstrict-flex-arrays'
>> Warn about inproper usages of flexible array members according to
>> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
>
> On Nov 18, 2022, at 11:31 AM, Kees Cook wrote:
>
> On Fri, Nov 18, 2022 at 03:19:07PM +0000, Qing Zhao wrote:
>> Hi, Richard,
>>
>> Honestly, it’s very hard for me to decide what’s the best way to handle the
>> interaction
>> between -fs
> On Nov 22, 2022, at 3:16 AM, Richard Biener wrote:
>
> On Mon, 21 Nov 2022, Qing Zhao wrote:
>
>>
>>
>>> On Nov 18, 2022, at 11:31 AM, Kees Cook wrote:
>>>
>>> On Fri, Nov 18, 2022 at 03:19:07PM +, Qing Zhao wrote:
>>>
> On Nov 22, 2022, at 9:10 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Nov 22, 2022, at 3:16 AM, Richard Biener wrote:
>>
>> On Mon, 21 Nov 2022, Qing Zhao wrote:
>>
>>>
>>>
>>>> On Nov 18, 2022, at 11:31 AM,
Hi, this is the 2nd version for this patch.
Per our discussion, I made the following change compared to the first
version:
1. The level of -Warray-bounds will NOT control how a trailing array
is considered as a flex array member anymore. Only the level of
-fstrict-flex-arrays will contro
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field of a structure if it's available,
otherwise according to the LEVEL of the option
'-fstrict-fl
> On Dec 1, 2022, at 11:42 AM, Kees Cook wrote:
>
> On Wed, Nov 30, 2022 at 02:25:56PM +0000, Qing Zhao wrote:
>> '-Wstrict-flex-arrays'
>> Warn about inproper usages of flexible array members according to
>> the LEVEL of the 'strict_flex_array
ote:
>
> On Thu, Dec 01, 2022 at 05:04:02PM +0000, Qing Zhao wrote:
>>
>>
>>> On Dec 1, 2022, at 11:42 AM, Kees Cook wrote:
>>>
>>> On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
>>>> '-Wstrict-flex-arrays'
>
esh Poyarekar wrote:
>
> On 2022-12-01 11:42, Kees Cook wrote:
>> On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
>>> '-Wstrict-flex-arrays'
>>> Warn about inproper usages of flexible array members according to
>>> the LEVEL of the
> On Dec 2, 2022, at 2:16 AM, Richard Biener wrote:
>
> On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
>
>> On 2022-12-01 11:42, Kees Cook wrote:
>>> On Wed, Nov 30, 2022 at 02:25:56PM +, Qing Zhao wrote:
>>>> '-Wstrict-flex-arrays'
>&
> On Dec 2, 2022, at 2:20 AM, Richard Biener wrote:
>
> On Fri, 2 Dec 2022, Richard Biener wrote:
>
>> On Thu, 1 Dec 2022, Siddhesh Poyarekar wrote:
>>
>>> On 2022-12-01 11:42, Kees Cook wrote:
>>>> On Wed, Nov 30, 2022 at 02:25:56PM +,
> On Dec 5, 2022, at 10:16 AM, Richard Biener wrote:
>
> On Fri, 2 Dec 2022, Qing Zhao wrote:
>
>>
>>
>>> On Dec 2, 2022, at 2:20 AM, Richard Biener wrote:
>>>
>>> On Fri, 2 Dec 2022, Richard Biener wrote:
>>>
>>>>
Hi, this is the 3rd version of the patch.
Per Richard's request, I split the patch into two seperate patches:
1. Update -Warray-bounds with -fstrict-flex-arrays.
2. Add a new warning option -Wstrict-flex-arrays.
I have bootstrapped and regression tested on both X86 and aarch64
without any issu
A. add the following to clarify the relationship between -Warray-bounds
and the LEVEL of -fstrict-flex-array:
By default, the trailing array of a structure will be treated as a
flexible array member by '-Warray-bounds' or '-Warray-bounds=N' if
it is declared as either a
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field of a structure if it's available,
otherwise according to the LEVEL of the option
'-fstrict-fl
Sorry, Please ignore this email.
Qing
> On Dec 6, 2022, at 11:14 AM, Qing Zhao wrote:
>
> '-Wstrict-flex-arrays'
> Warn about inproper usages of flexible array members according to
> the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
'-Wstrict-flex-arrays'
Warn about inproper usages of flexible array members according to
the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
the trailing array field of a structure if it's available,
otherwise according to the LEVEL of the option
'-fstrict-fl
Hi,
> On Dec 9, 2021, at 12:13 PM, Qing Zhao via Gcc-patches
> wrote:
>>
>>> + return;
>>> +
>>> + /* Get the variable declaration location from the def_stmt. */
>>> + var_decl_loc = gimple_location (def_stmt);
>>> +
>
> On Dec 14, 2021, at 4:06 PM, Martin Sebor wrote:
>
>
Dynamically creating the string seems quite cumbersome here, and
it leaks the allocated block. I wonder if it might be better to
remove the gmsgid argument from the function and assign it to
one of the litera
> On Dec 15, 2021, at 11:33 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Dec 14, 2021, at 4:06 PM, Martin Sebor wrote:
>>
>>>>>>
>>>>>
>>>>> Dynamically creating the string seems quite cumbersome here,
Hi,
This is the 2nd version of the patch.
The original patch is at:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586341.html
In addition to resolve the two issues mentioned in the original patch,
This patch also can be used as a very good workaround for the issue in PR103720
https://g
Hi,
I’d like to ping the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587014.html
Please take a look and let me know whether it’s okay for committing?
Thanks.
Qing
> On Dec 16, 2021, at 9:59 AM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi,
>
> This is
Hi, Richard,
Thanks a lot for the review and questions.
See my reply embedded below:
> On Jan 5, 2022, at 4:33 AM, Richard Biener wrote:
>
> On Thu, Dec 16, 2021 at 5:00 PM Qing Zhao wrote:
>>
>> Hi,
>>
>> This is the 2nd version of the patch.
>>
> On Jan 5, 2022, at 10:59 AM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi, Richard,
>
> Thanks a lot for the review and questions.
> See my reply embedded below:
>
>
>> On Jan 5, 2022, at 4:33 AM, Richard Biener
>> wrote:
>>
>&g
uses.
In order to improve such situation, changing the 3rd parameter of the function
.DEFERRED_INIT to the name string of the variable will provide necessary
information to uninitialized warning analysis to make the missing warning
possible.
gcc/ChangeLog:
2022-01-10 qing zhao
gs + -ftrivial-auto-var-init
are adjusted to reflect the fact that we can issue warnings for address taken
variables.
gcc/ChangeLog:
2022-01-10 qing zhao
* tree-ssa-uninit.c (warn_uninit): Handle .DEFERRED_INIT call with an
anonymous SSA_NAME specially.
(ch
> On Jan 11, 2022, at 7:53 AM, Richard Biener
> wrote:
>
> On Tue, Jan 11, 2022 at 12:58 AM Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>> I splited the previous patch for “Enable -Wuninitialized +
>> -ftrivial-auto-var-init for address taken variabl
Hi, Richard,
> On Jan 11, 2022, at 7:43 AM, Richard Biener
> wrote:
>
1. Add some meaningful temporaries to break the long expression to make it
Readable. And also add comments to explain the purpose of the statement;
2. Resolve the memory leakage of the dy
FYI.
Just committed this patch to gcc12 as:
https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359118.html
Qing
> On Jan 11, 2022, at 9:38 AM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Jan 11, 2022, at 7:53 AM, Richard Biener
>> wrote:
>>
>>
> On Jan 12, 2022, at 4:46 AM, Richard Biener
> wrote:
>
> On Tue, Jan 11, 2022 at 5:32 PM Qing Zhao wrote:
>>
>>>>> + /* Ignore the call to .DEFERRED_INIT that define the original
>>>>> +var itself.
ss warning messages when needed;
The current testing cases for uninitialized warnings + -ftrivial-auto-var-init
are adjusted to reflect the fact that we can issue warnings for address taken
variables.
gcc/ChangeLog:
2022-01-12 qing zhao
* tree-ssa-uninit.c (warn_uninit): Handle .DEFERRE
> On Jan 14, 2022, at 12:58 PM, Martin Sebor wrote:
>
> On 1/14/22 11:29, Qing Zhao wrote:
>>> On Jan 14, 2022, at 12:11 PM, Martin Sebor wrote:
>>>
>>> On 1/14/22 09:30, Qing Zhao wrote:
>>>>> On Jan 14, 2022, at 6:45 AM, Richard Biener
or not to suppress warning messages when needed;
The current testing cases for uninitialized warnings + -ftrivial-auto-var-init
are adjusted to reflect the fact that we can issue warnings for address taken
variables.
gcc/ChangeLog:
2022-01-14 qing zhao
* tree-ssa-uninit.c (warn_unin
Thanks.
I just committed the patch to gcc12 as:
https://gcc.gnu.org/pipermail/gcc-cvs/2022-January/359400.html
Qing
> On Jan 17, 2022, at 5:36 AM, Richard Biener
> wrote:
>
> On Sat, Jan 15, 2022 at 5:49 PM Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>>
Hi,
Recently, we discovered some floating point precision diffs when using GCC8 to
build our
application on arm64: After some investigation, it turns out that this is due
to the
-ffp-contract=fast option that is on by default. Therefore, we have to
explicitly add
-ffp-contract=off and do a f
> On Mar 16, 2023, at 12:31 PM, Andrew Pinski wrote:
>
> On Thu, Mar 16, 2023 at 9:25 AM Qing Zhao via Gcc-patches
> wrote:
>>
>> Hi,
>>
>> Recently, we discovered some floating point precision diffs when using GCC8
>> to build our
>> ap
> On Mar 16, 2023, at 12:53 PM, Jakub Jelinek wrote:
>
> On Thu, Mar 16, 2023 at 04:38:41PM +0000, Qing Zhao via Gcc-patches wrote:
>>> NO. We have this debate every few years and such.
>>
>> So, what’s the major reason we keep the default that is not IEEE754
&
rgs_stdarg_p to save space in the IR.
and corresponding changes to support such sharing.
3. I also changed the code inside tree-object-size.cc to make it cleaner
and easier to be understood.
bootstrapped and regression tested on aarch64 and x86.
Okay for commit?
thanks.
Qing
Qing Zha
GCC extension accepts the case when a struct with a flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size per
-fstrict-flex-arrays.
gcc/c/ChangeLog:
PR tree-optimization/101832
* c-dec
on a structure with a C99 flexible array member being nested in
another structure. (PR77650)
"GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.
There are two situations:
Hi,
> On Mar 16, 2023, at 12:53 PM, Jakub Jelinek wrote:
>
> On Thu, Mar 16, 2023 at 04:38:41PM +0000, Qing Zhao via Gcc-patches wrote:
>>> NO. We have this debate every few years and such.
>>
>> So, what’s the major reason we keep the default that is not
Thanks a lot for the info.
Qing
> On Mar 20, 2023, at 6:25 PM, Jakub Jelinek wrote:
>
> On Mon, Mar 20, 2023 at 10:05:57PM +0000, Qing Zhao via Gcc-patches wrote:
>> My question: is the above section the place in C standard “explicitly allows
>> contractions”? If
> On Mar 20, 2023, at 6:25 PM, Jakub Jelinek wrote:
>
> On Mon, Mar 20, 2023 at 10:05:57PM +0000, Qing Zhao via Gcc-patches wrote:
>> My question: is the above section the place in C standard “explicitly allows
>> contractions”? If not, where it is in C standard?
>
&g
> On Mar 21, 2023, at 12:56 PM, Paul Koning wrote:
>
>
>
>> On Mar 21, 2023, at 11:01 AM, Qing Zhao via Gcc-patches
>> wrote:
>>
>> ...
>> Most of the compiler users are not familiar with language standards, or no
>> access to language stan
> On Mar 21, 2023, at 1:59 PM, Jeff Law via Gcc-patches
> wrote:
>
>
>
> On 3/21/23 11:00, Qing Zhao via Gcc-patches wrote:
>>> On Mar 21, 2023, at 12:56 PM, Paul Koning wrote:
>>>
>>>
>>>
>>>> On
> On Mar 21, 2023, at 3:51 PM, Jeff Law wrote:
>
>
>
> On 3/21/23 13:01, Qing Zhao wrote:
>
>> The code previously worked now has some issue since we added some new stuff
>> into standard, and the compiler added some new transformation based on this
>>
> On Mar 22, 2023, at 8:33 AM, Alexander Monakov wrote:
>
>
> On Mon, 20 Mar 2023, Jakub Jelinek via Gcc-patches wrote:
>
>> On Mon, Mar 20, 2023 at 10:05:57PM +, Qing Zhao via Gcc-patches wrote:
>>> My question: is the above section the place in C st
> On Mar 22, 2023, at 9:57 AM, Richard Biener via Gcc-patches
> wrote:
>
> On Wed, Mar 22, 2023 at 1:26 PM Alexander Monakov wrote:
>>
>>
>> On Wed, 22 Mar 2023, Richard Biener wrote:
>>
>>> I think it's even less realistic to expect users to know the details of
>>> floating-point math. S
Ping…
Please let me know if you have any further comments on the patch.
thanks.
Qing
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle.com>>
Subject: [V5][PATCH 0/2] Handle component_ref to a structure/union field
including FAM for builtin_object_size
Date: March 16, 202
Ping…
Please let me know if you have any further comments on the patch.
thanks.
Qing
Begin forwarded message:
From: Qing Zhao mailto:qing.z...@oracle.com>>
Subject: [V5][PATCH 1/2] Handle component_ref to a structre/union field
including flexible array member [PR101832]
Date: March 16
1301 - 1400 of 1419 matches
Mail list logo
