ughts?
>
> * * *
>
> Cross ref: The patch adding the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously
> in this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08
-25 11:24, Qing Zhao wrote:
>> Provide a new counted_by attribute to flexible array member field.
>
> The obligatory "I can't ack the patch but here's a review" disclaimer :)
>
>> 'counted_by (COUNT)'
>> The 'counted_by' attrib
>>> + member FIELD_DECL is a valid field of the containing structure's
>>> fieldlist,
>>> + FIELDLIST, Report error and remove this attribute when it's not. */
>>> +static void
>>> +verify_counted_by_attribute (tree fieldlist, tree field_decl)
>>> +{
>>> + tree attr_counted_by = lookup_att
> On Oct 18, 2023, at 11:18 AM, Siddhesh Poyarekar wrote:
>
> On 2023-10-18 10:51, Qing Zhao wrote:
>>>>> + member FIELD_DECL is a valid field of the containing structure's
>>>>> fieldlist,
>>>>> + FIELDLIST, Report error and
> On Oct 6, 2023, at 4:01 PM, Martin Uecker wrote:
>
> Am Freitag, dem 06.10.2023 um 06:50 -0400 schrieb Siddhesh Poyarekar:
>> On 2023-10-06 01:11, Martin Uecker wrote:
>>> Am Donnerstag, dem 05.10.2023 um 15:35 -0700 schrieb Kees Cook:
On Thu, Oct 05, 2023 at 04:08:52PM -0400, Siddhesh P
Marek,
Sorry for the late comment (I was just back from a long vacation immediate
after Cauldron).
One question:
Is the option “-fhandened” for production build or for development build?
If it’s for development build, then adding -ftrivial-auto-var-init=pattern is
reasonable since the major
Hi, Sid,
Thanks a lot for the detailed comments.
See my responds embedded below.
Qing
> On Oct 5, 2023, at 4:01 PM, Siddhesh Poyarekar wrote:
>
>
>
> On 2023-08-25 11:24, Qing Zhao wrote:
>> Use the counted_by atribute info in builtin object size to compute the
> On Oct 5, 2023, at 4:08 PM, Siddhesh Poyarekar wrote:
>
> On 2023-08-25 11:24, 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:
&g
this separate patch for issuing
warning for strcmp/strncmp when
-Wstringop-overflow is specified.
The new patch is as following, please take a look at it.
thanks.
Qing
gcc/ChangeLog
+2018-07-02 Qing Zhao
+
+ PR middle-end/78809
+ * builtins.c (expand_builtin_memcmp): Inline the calls
patch for issuing
warning for strcmp/strncmp when
-Wstringop-overflow is specified.
The new patch is as following, please take a look at it.
thanks.
Qing
gcc/ChangeLog
+2018-07-02 Qing Zhao
+
+ PR middle-end/78809
+ * builtins.c (expand_builtin_memcmp): Inline the calls first
patch is needed.
if this is needed, let me know, I can work on this separate patch for issuing
warning for strcmp/strncmp when
-Wstringop-overflow is specified.
The new patch is as following, please take a look at it.
thanks.
Qing
gcc/ChangeLog
+2018-07-02 Qing Zhao
+
+ PR middle-end
Hi, Martin,
thanks a lot for your comments.
> On Jul 5, 2018, at 11:30 AM, Martin Sebor wrote:
>
> One of the basic design principles that I myself have
> accidentally violated in the past is that warning options
> should not impact the emitted object code. I don't think
> your patch actually
> On Jul 9, 2018, at 3:25 PM, Martin Sebor wrote:
>
> check_access() calls warning_at() to issue warnings, and that
> function only issues warnings if they are enabled, so the guard
> isn't necessary to make it work this way.
Okay I see.
then, in the current code: (for routine expand_builtin_
Richard and Martin,
thanks for the info.
> On Jul 10, 2018, at 11:29 AM, Richard Biener wrote:
>> Is the above condition on variable warn_stringop_overflow unnecessary?
>> all the warnings inside check_access are controlled by
>> OPT_Wstringop_overflow_.
>
> Well, the condition certainly saves
2. in the testsuite, change the new testcase strcmpopt_6.c to inhibit inlining
when check_access
detects error (Not depend on whether the warning option is ON or not).
the following is the new patch, tested on both X86 and aarch64, no regression.
Okay for thunk?
thanks.
Qing
gcc/ChangeLog:
+2
thank you.
the patch was just committed into trunk as:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262636
<https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262636>
Qing
> On Jul 12, 2018, at 12:03 PM, Jeff Law wrote:
>
>>
>> gcc/ChangeLo
should use unsigned char for all strcmp/strncmp/memcmp.
the change is quite simple, and I have tested it on X86, aarch64 and powerPC,
no regressions.
Okay for trunk?
Qing
gcc/ChangeLog:
+2018-07-19 Qing Zhao
+
+ * builtins.c (expand_builtin_memcmp): Delete the last parameter for
+
Jakub,
thanks a lot for you review and comments.
> On Jul 19, 2018, at 12:31 PM, Jakub Jelinek wrote:
>
> On Thu, Jul 19, 2018 at 11:49:16AM -0500, Qing Zhao wrote:
>> As Wilco mentioned in PR78809 after I checked in the last part of
>> implementation of inline str
> On Jul 19, 2018, at 2:24 PM, Jakub Jelinek wrote:
>
> On Thu, Jul 19, 2018 at 02:06:16PM -0500, Qing Zhao wrote:
>>> If you expand it as (int) ((unsigned char *)p)[n] - (int) ((unsigned char
>>> *)q)[n]
>>> then aren't you relying on int type to hav
.
and
3. also updated comments of routine inline_string_cmp to reflect the conversions
in the expanded code.
have tested on X86 and aarch64. No regressions.
Okay for thunk?
Qing
gcc/ChangeLog:
+2018-07-20 Qing Zhao
+
+ * builtins.c (expand_builtin_memcmp): Delete the last parameter for
> On Jul 20, 2018, at 9:59 AM, Jakub Jelinek wrote:
>
> On Fri, Jul 20, 2018 at 09:53:24AM -0500, Qing Zhao wrote:
>> +2018-07-20 Qing Zhao
>> +
>> + * builtins.c (expand_builtin_memcmp): Delete the last parameter for
>> + call to
the patch was committed as:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262907
<https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=262907>
thanks.
Qing
> On Jul 20, 2018, at 9:59 AM, Jakub Jelinek wrote:
>
> On Fri, Jul 20, 2018 at 09:53:24AM -0500, Qi
Hi,
As Wilco suggested, the new added strcmp/strncmp inlining should be only
enabled with O2 and above.
this is the simple patch for this change.
tested on both X86 and aarch64.
Okay for thunk?
Qing
gcc/ChangeLog:
+2018-07-25 Qing Zhao
+
+ * builtins.c
> On Jul 26, 2018, at 3:26 AM, Richard Biener wrote:
>
> On Wed, 25 Jul 2018, Qing Zhao wrote:
>
>> Hi,
>>
>> As Wilco suggested, the new added strcmp/strncmp inlining should be only
>> enabled with O2 and above.
>>
>> this is the simple patc
adding the new warning is r14-2197-g070a6bf0bdc6761
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-June/385730.html (cf. previously
> in this thread)
>
>
> * * *
>
> Regarding the changes.html wording:
>
> On 07.08.23 16:22, Qing Zhao via Gcc-patches wrote:
>
>> Comp
Sid,
(Richard, can you please help me to make sure this? Thanks a lot)
I studied a little bit more on the following question you raised during the
review process:
For the following small testing case:
1 struct annotated {
2 int foo;
3 char array[] __attribute__((counted_by (foo)));
> On Oct 20, 2023, at 2:22 PM, Richard Biener
> wrote:
>
>
>
>> Am 20.10.2023 um 19:09 schrieb Qing Zhao :
>>
>> Sid,
>>
>> (Richard, can you please help me to make sure this? Thanks a lot)
>>
>> I studied a little bit more o
> On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
>
> On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote:
>> Am Donnerstag, dem 19.10.2023 um 16:33 -0700 schrieb Kees Cook:
>>> On Wed, Oct 18, 2023 at 09:11:43PM +, Qing Zhao wrote:
>>>> As I r
> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-20 14:38, Qing Zhao wrote:
>> How about the following:
>> Add one more parameter to __builtin_dynamic_object_size(), i.e
>> __builtin_dynamic_object_size (_1,1,array_annotated->foo)?
>
> On Oct 23, 2023, at 3:57 AM, Richard Biener
> wrote:
>
> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
>>
>>
>>
>>> On Oct 20, 2023, at 3:10 PM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-10-20 14:38, Qing Zhao wrote:
>
> On Oct 23, 2023, at 8:34 AM, Richard Biener
> wrote:
>
> On Mon, Oct 23, 2023 at 1:27 PM Siddhesh Poyarekar
> wrote:
>>
>> On 2023-10-23 03:57, Richard Biener wrote:
>>> On Fri, Oct 20, 2023 at 10:41 PM Qing Zhao wrote:
>>>>
>>
> On Oct 23, 2023, at 11:57 AM, Richard Biener
> wrote:
>
>
>
>> Am 23.10.2023 um 16:56 schrieb Qing Zhao :
>>
>>
>>
>>> On Oct 23, 2023, at 3:57 AM, Richard Biener
>>> wrote:
>>>
>>>> On Fri, Oct 20, 2023
> On Oct 20, 2023, at 3:54 PM, Martin Uecker wrote:
>
> Am Freitag, dem 20.10.2023 um 18:48 + schrieb Qing Zhao:
>>
>>> On Oct 20, 2023, at 2:34 PM, Kees Cook wrote:
>>>
>>> On Fri, Oct 20, 2023 at 11:50:11AM +0200, Martin Uecker wrote:
>>
> On Oct 23, 2023, at 2:06 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 16:37 + schrieb Qing Zhao:
>>
>>> On Oct 23, 2023, at 11:57 AM, Richard Biener
>>> wrote:
>>>
>>>
>>>
>>>> Am 23.10.2023 um 16:
> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
>> Am Montag, dem 23.10.2023 um 16:37 +0000 schrieb Qing Zhao:
>>>
>>>> On Oct 23, 2023, at 11:57 AM, Richard Biener
>>>>
> On Oct 23, 2023, at 2:43 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-23 14:06, Martin Uecker wrote:
>> We should aim for a good integration with the BDOS pass, so
>> that it can propagate the information further, e.g. the
>> following should work:
>> struct { int L; char buf[] __counted_by(L
> On Oct 23, 2023, at 3:37 PM, Martin Uecker wrote:
>
> Am Montag, dem 23.10.2023 um 19:00 + schrieb Qing Zhao:
>>
>>> On Oct 23, 2023, at 2:31 PM, Martin Uecker wrote:
>>>
>>> Am Montag, dem 23.10.2023 um 20:06 +0200 schrieb Martin Uecker:
>
Hi, Sid,
Really appreciate for your example and detailed explanation. Very helpful.
I think that this example is an excellent example to show (almost) all the
issues we need to consider.
I slightly modified this example to make it to be compilable and run-able, as
following:
(but I still canno
> On Oct 24, 2023, at 5:03 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-24 16:30, Qing Zhao wrote:
>> Situation 2: With O0, the routine “get_size_from” was NOT inlined into
>> “foo”, therefore, the call to __bdos is Not in the same routine as the
>> instantiation
> On Oct 24, 2023, at 4:38 PM, Martin Uecker wrote:
>
> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>> Hi, Sid,
>>
>> Really appreciate for your example and detailed explanation. Very helpful.
>> I think that this example is an excellent
> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-24 18:51, Qing Zhao wrote:
>> Thanks for the proposal!
>> So what you suggested is:
>> For every x.buf, change it as a __builtin_with_size(x.buf, x.L) in the FE,
>> then the call to th
iener:
>>>>
>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>
>>>>> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>>>>>> Hi, Sid,
>>>>>>
>>>>>> Really appreciat
t;>>> Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
>>>>>
>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>>
>>>>>> Am Dienstag, dem 24.10.2023 um 20:30 + schrieb Qing Zhao:
>>>>&
> On Oct 25, 2023, at 10:50 AM, Siddhesh Poyarekar wrote:
>
> On 2023-10-25 09:27, Qing Zhao wrote:
>>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar wrote:
>>>
>>> On 2023-10-24 18:51, Qing Zhao wrote:
>>>> Thanks for the proposal!
>
> On Oct 25, 2023, at 11:38 AM, Richard Biener
> wrote:
>
>
>
>> Am 25.10.2023 um 16:50 schrieb Siddhesh Poyarekar :
>>
>> On 2023-10-25 09:27, Qing Zhao wrote:
>>>>> On Oct 24, 2023, at 7:56 PM, Siddhesh Poyarekar
>>>
> On Oct 25, 2023, at 6:06 PM, Kees Cook wrote:
>
> On Wed, Oct 25, 2023 at 01:27:29PM +0000, Qing Zhao wrote:
>> A. Add an additional argument, the size parameter, to __bdos,
>> A.1, during FE;
>> A.2, during gimplification phase;
>
> I just wanted
> On Oct 26, 2023, at 1:21 AM, Jakub Jelinek wrote:
>
> On Wed, Oct 25, 2023 at 07:03:43PM +0000, Qing Zhao wrote:
>> For the code generation impact:
>>
>> turning the original x.buf
>> to a builtin function call
>> __builtin_with_access_and_size(x
> On Oct 26, 2023, at 4:56 AM, Richard Biener
> wrote:
>
> On Thu, Oct 26, 2023 at 7:22 AM Jakub Jelinek wrote:
>>
>> On Wed, Oct 25, 2023 at 07:03:43PM +, Qing Zhao wrote:
>>> For the code generation impact:
>>>
>>> turning
Am Mittwoch, dem 25.10.2023 um 08:43 +0200 schrieb Richard Biener:
>>>>>>>>
>>>>>>>>> Am 24.10.2023 um 22:38 schrieb Martin Uecker :
>>>>>>>>>
>>>>>>>>> Am Dienstag, dem 24.10.2023 um
>>>>>>>
>>>>>>> Am Mittwoch, dem 25.10.2023 um 06:25 -0400 schrieb Siddhesh Poyarekar:
>>>>>>>>> On 2023-10-25 04:16, Martin Uecker wrote:
>>>>>>>>> Am Mittwoch, dem 25.10.2
> On Oct 26, 2023, at 1:05 PM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 16:41 + schrieb Qing Zhao:
>>
>>> On Oct 26, 2023, at 5:20 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 10:45 +0200 schrieb Richard Bi
I guess that what Kees wanted, ""fill the array without knowing the actual
final size" code pattern”, as following:
>> struct foo *f;
>> char *p;
>> int i;
>>
>> f = alloc(maximum_possible);
>> f->count = 0;
>> p = f->buf;
>>
>> for (i; data_is_available() &&
> On Oct 27, 2023, at 3:21 AM, Martin Uecker wrote:
>
> Am Donnerstag, dem 26.10.2023 um 19:57 + schrieb Qing Zhao:
>> I guess that what Kees wanted, ""fill the array without knowing the actual
>> final size" code pattern”, as following:
>&g
> On Oct 27, 2023, at 10:53 AM, Martin Uecker wrote:
>
> Am Freitag, dem 27.10.2023 um 14:32 + schrieb Qing Zhao:
>>
>>> On Oct 27, 2023, at 3:21 AM, Martin Uecker wrote:
>>>
>>> Am Donnerstag, dem 26.10.2023 um 19:57 + schrieb Qing Zhao:
About where we should insert the new __builtin_with_access_and_size:
> On Oct 26, 2023, at 2:54 PM, Qing Zhao wrote:
>
>
>
>> On Oct 26, 2023, at 10:05 AM, Richard Biener
>> wrote:
>>
>>
>>
>>> Am 26.10.2023 um 12:14 schrieb Martin Uec
Okay, thanks for the explanation.
We will keep this in mind.
Qing
> On Oct 27, 2023, at 1:19 PM, Kees Cook wrote:
>
> On Fri, Oct 27, 2023 at 03:10:22PM +0000, Qing Zhao wrote:
>> Since the dynamic array support is quite important to the kernel (is this
>> true, Kees? )
all the help.
Qing.
Represent the missing dependence for the "counted_by" attribute and its
consumers
Qing Zhao
10/30/2023
==
The whole discussion is at:
https://gcc.gnu.org/pip
> On Oct 31, 2023, at 1:35 PM, Siddhesh Poyarekar wrote:
>
> On 2023-10-31 12:26, Qing Zhao wrote:
>> Hi,
>> I wrote a summary based on our extensive discussion, hopefully this can be
>> served as an informal proposal.
>> Please take a look at it and let
> On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
>
> On Tue, 31 Oct 2023, Qing Zhao wrote:
>
>> 2.3 A new semantic requirement in the user documentation of "counted_by"
>>
>> For the following structure including a FAM with a counted_by attribute:
> On Nov 1, 2023, at 11:00 AM, Martin Uecker wrote:
>
> Am Mittwoch, dem 01.11.2023 um 14:47 + schrieb Qing Zhao:
>>
>>> On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
>>>
>>> On Tue, 31 Oct 2023, Qing Zhao wrote:
>>>
>>>&
Joseph and Martin,
For the task to replace every reference to a FAM field with an call to
.ACCESS_WITH_SIZE,
Where in the C FE I should look at?
Thanks a lot for the help.
Qing
> On Nov 2, 2023, at 3:57 AM, Richard Biener wrote:
>
> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wrote:
>>
>>
>>
>>> On Oct 31, 2023, at 6:14 PM, Joseph Myers wrote:
>>>
>>> On Tue, 31 Oct 2023, Qing Zhao wrote:
>>>
&
> On Nov 2, 2023, at 9:54 AM, Richard Biener wrote:
>
> On Thu, Nov 2, 2023 at 2:50 PM Qing Zhao wrote:
>>
>>
>>
>>> On Nov 2, 2023, at 3:57 AM, Richard Biener
>>> wrote:
>>>
>>> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wro
Thanks a lot for raising these issues.
If I understand correctly, the major question we need to answer is:
For the following example: (Jakub mentioned this in an early message)
1 struct S { int a; char b __attribute__((counted_by (a))) []; };
2 struct S s;
3 s.a = 5;
4 char *p = &s.b[
> On Nov 2, 2023, at 7:52 AM, Richard Biener wrote:
>
> On Thu, Nov 2, 2023 at 11:40 AM Jakub Jelinek wrote:
>>
>> On Thu, Nov 02, 2023 at 11:18:09AM +0100, Richard Biener wrote:
Or, if we want to pay further price, .ACCESS_WITH_SIZE could take as one of
the arguments not the size v
> On Nov 2, 2023, at 8:09 AM, Jakub Jelinek wrote:
>
> On Thu, Nov 02, 2023 at 12:52:50PM +0100, Richard Biener wrote:
>>> What I meant is to emit
>>> tmp_4 = .ACCESS_WITH_SIZE (&s.b[0], &s.a, (typeof (&s.a)) 0);
>>> p_5 = &tmp_4[2];
>>> i.e. don't associate the pointer with a value of the siz
> On Nov 3, 2023, at 2:22 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 07:07:36AM +0100, Martin Uecker wrote:
>> Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill Wendling:
>>> On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote:
>>>>
>&g
> On Nov 3, 2023, at 10:46 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 02:32:04PM +0000, Qing Zhao wrote:
>>> Why? It doesn't really matter. The options are
>>> A. p is at &s.b[2] associated with &s.a and int type (or size of int
>>&g
nt or suggestion.
Qing
On Nov 3, 2023, at 2:32 AM, Martin Uecker wrote:
>
>
> Am Freitag, dem 03.11.2023 um 07:22 +0100 schrieb Jakub Jelinek:
>> On Fri, Nov 03, 2023 at 07:07:36AM +0100, Martin Uecker wrote:
>>> Am Donnerstag, dem 02.11.2023 um 17:28 -0700 schrieb Bill
> On Nov 3, 2023, at 12:30 PM, Jakub Jelinek wrote:
>
> On Fri, Nov 03, 2023 at 04:20:57PM +0000, Qing Zhao wrote:
>> So, based on the discussion so far, We will define the .ACCESS_WITH_SIZE as
>> following:
>>
>> .ACCESS_WITH_SIZE (REF_TO_OBJ, REF_TO_SIZE
> On Nov 2, 2023, at 8:13 PM, Bill Wendling wrote:
>
> On Thu, Nov 2, 2023 at 1:00 AM Richard Biener
> wrote:
>>
>> On Wed, Nov 1, 2023 at 3:47 PM Qing Zhao wrote:
>>>
>>>
>>>
>>>> On Oct 31, 2023, at 6:14 PM, Josep
-obtaining purpose in the source
code.
I will update the proposal one more time.
thanks.
Qing
> On Nov 2, 2023, at 8:28 PM, Bill Wendling wrote:
>
> On Thu, Nov 2, 2023 at 1:36 PM Qing Zhao wrote:
>>
>> Thanks a lot for raising these issues.
>>
>> If I understand
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
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
> 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
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
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
> 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:
>>&
==
>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 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
> 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
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 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
> 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 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:
>>>
&
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)
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
Thank you!
Just committed the change at:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=277344
<https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=277344>
Qing
> On Oct 23, 2019, at 5:15 AM, Martin Liška wrote:
>
> On 10/21/19 5:32 PM, Qing Zhao wrote
Ping on this patch set.
Thanks a lot!
Qing
> On Feb 16, 2024, at 14:47, Qing Zhao wrote:
>
> Hi,
>
> This is the 6th version of the patch.
>
> compare with the 5th version, the only difference is:
>
> 1. Add the 6th argument to .ACCESS_WITH_SIZE
> to carry
Sid,
Thanks a lot for your time to review the code.
See my reply below:
On Mar 11, 2024, at 10:57, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
return true;
else
return targetm.attribute_takes_identifier_p (attr_id);
@@ -2806,6 +2811,53
> On Mar 11, 2024, at 13:09, Siddhesh Poyarekar wrote:
>
>
>
> On 2024-02-16 14:47, Qing Zhao wrote:
>> Including the following changes:
>> * The definition of the new internal function .ACCESS_WITH_SIZE
>> in internal-fn.def.
>> * C FE converts ever
On Mar 11, 2024, at 13:11, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-object-size-common.h: Add a new
On Mar 11, 2024, at 13:15, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc/testsuite/ChangeLog:
* gcc.dg/ubsan/flex-array
On Mar 13, 2024, at 15:19, Qing Zhao wrote:
On Mar 11, 2024, at 13:15, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/c-family/ChangeLog:
* c-ubsan.cc (get_bound_from_access_with_size): New function.
(ubsan_instrument_bounds): Handle call to .ACCESS_WITH_SIZE.
gcc
On Mar 13, 2024, at 15:17, Qing Zhao wrote:
On Mar 11, 2024, at 13:11, Siddhesh Poyarekar wrote:
On 2024-02-16 14:47, Qing Zhao wrote:
gcc/ChangeLog:
* tree-object-size.cc (access_with_size_object_size): New function.
(call_object_size): Call the new function.
gcc/testsuite/ChangeLog
> On Mar 18, 2024, at 12:30, Siddhesh Poyarekar wrote:
>
> On 2024-03-18 12:28, Qing Zhao wrote:
>>>> This should probably bail out if object_size_type & OST_DYNAMIC == 0.
>>> Okay. Will add this.
>> When add this into access_with_si
Currently, the OST_DYNAMIC information is not passed to
early_object_sizes phase. Pass this information to it, and adjust the code
and testing case accordingly.
bootstrapped and regress tested on both x86 and aarch64. no issue.
Okay for trunk?
thanks.
Qing
gcc/ChangeLog:
* tree-obj
On Mar 19, 2024, at 09:46, Jakub Jelinek wrote:
On Tue, Mar 19, 2024 at 01:14:51PM +, Qing Zhao wrote:
Currently, the OST_DYNAMIC information is not passed to
early_object_sizes phase. Pass this information to it, and adjust the code
and testing case accordingly.
Can you explain why do
Hi,
This is the 7th version of the patch.
compare with the 6th version, the difference are:
updates per Siddhesh's comments:
1. update the error messages in "handle_counted_by_attribute"
then update the testing case accordingly;
2. update the error messages in "verify_counted_by_attribute"
1 - 100 of 1251 matches
Mail list logo
