> On May 23, 2024, at 10:13, David Malcolm wrote:
>
> On Thu, 2024-05-23 at 14:03 +0000, Qing Zhao wrote:
>
> [...snip...]
>
>> Is “location_adhoc_data” an available data structure in current GCC?
>> I just searched GCC source tree, cannot find it.
>
>
Thank you for the comments. See my answers below:
Joseph, please see the last question, I need your help on it. Thanks a lot for
the help.
Qing
> On May 28, 2024, at 03:38, Richard Biener wrote:
>
> On Fri, Apr 12, 2024 at 3:54 PM Qing Zhao wrote:
>>
>> Including
> On May 28, 2024, at 03:39, Richard Biener wrote:
>
> On Fri, Apr 12, 2024 at 3:54 PM Qing Zhao wrote:
>>
>
> I have no comments here, if Siddesh is OK with this I approve.
thanks.
Qing
>
>> gcc/ChangeLog:
>>
>>* tree-object-size.cc (a
> On May 28, 2024, at 03:43, Richard Biener wrote:
>
> On Fri, Apr 12, 2024 at 3:55 PM Qing Zhao wrote:
>>
>> to carry the TYPE of the flexible array.
>>
>> Such information is needed during tree-object-size.cc.
>>
>> We cannot use the result t
> On May 29, 2024, at 02:57, Richard Biener wrote:
>
> On Tue, May 28, 2024 at 11:09 PM Qing Zhao wrote:
>>
>> Thank you for the comments. See my answers below:
>>
>> Joseph, please see the last question, I need your help on it. Thanks a lot
>> for
Richard and Joseph:
> On May 28, 2024, at 17:09, Qing Zhao wrote:
>
>>>
>>> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
>>> index fa17eff551e8..d75b23668925 100644
>>> --- a/gcc/varasm.cc
>>> +++ b/gcc/varasm.cc
>>> @@ -5082,6
Hi,
This is the 10th version of the patch.
Which is rebased on the latest trunk.
Compare with the 9th version, all the difference are in patch #2, including
a small C FE change in the routine "digest_init". all others are middle-end
changes.
please review the changes for the patch #2:
updates p
'counted_by (COUNT)'
The 'counted_by' attribute may be attached to the C99 flexible
array member of a structure. It indicates that the number of the
elements of the array is given by the field "COUNT" in the
same structure as the flexible array member.
GCC may use this inf
Including the following changes:
* The definition of the new internal function .ACCESS_WITH_SIZE
in internal-fn.def.
* C FE converts every reference to a FAM with a "counted_by" attribute
to a call to the internal function .ACCESS_WITH_SIZE.
(build_component_ref in c_typeck.cc)
This includ
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-counted-by-bounds-2.c: New test.
* gcc.dg/ubsan/flex-array-counted
to carry the TYPE of the flexible array.
Such information is needed during tree-object-size.cc.
We cannot use the result type or the type of the 1st argument
of the routine .ACCESS_WITH_SIZE to decide the element type
of the original array due to possible type casting in the
source code.
gcc/c/C
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 macro EXPECT.
* gcc.dg/flex-array-counted-by-3.c: New test.
> On May 30, 2024, at 15:43, Joseph Myers wrote:
>
> On Thu, 30 May 2024, Qing Zhao wrote:
>
>> In order to make this working, the routine digest_init in c-typeck.cc
>> is updated to fold calls to .ACCESS_WITH_SIZE to its first argument
>> when require_
> On May 31, 2024, at 08:58, Richard Biener wrote:
>
> On Thu, 30 May 2024, Qing Zhao wrote:
>
>> Including the following changes:
>> * The definition of the new internal function .ACCESS_WITH_SIZE
>> in internal-fn.def.
>> * C FE converts every r
> On May 23, 2024, at 07:46, Richard Biener wrote:
>
> On Wed, May 22, 2024 at 8:53 PM Qing Zhao wrote:
>>
>>
>>
>>> On May 22, 2024, at 03:38, Richard Biener
>>> wrote:
>>>
>>> On Tue, May 21, 2024 at 11:36 PM David Mal
> On Jun 3, 2024, at 02:29, Richard Biener wrote:
>
> On Fri, May 31, 2024 at 11:23 PM Qing Zhao wrote:
>>
>>
>>
>>> On May 23, 2024, at 07:46, Richard Biener
>>> wrote:
>>>
>>> On Wed, May 22, 2024 at 8:53 PM Qing Zhao wr
> On Jun 4, 2024, at 03:43, Richard Biener wrote:
>
> On Mon, Jun 3, 2024 at 4:48 PM David Malcolm wrote:
>>
>> On Mon, 2024-06-03 at 08:29 +0200, Richard Biener wrote:
>>> On Fri, May 31, 2024 at 11:23 PM Qing Zhao
>>> wrote:
>>>>
&
> On Jun 4, 2024, at 17:55, David Malcolm wrote:
>
> On Fri, 2024-05-31 at 13:11 +0000, Qing Zhao wrote:
>>
>>
>>> On May 31, 2024, at 08:58, Richard Biener
>>> wrote:
>>>
>>> On Thu, 30 May 2024, Qing Zhao wrote:
>>>
>
> On Jun 5, 2024, at 03:26, Richard Biener wrote:
>
> On Tue, Jun 4, 2024 at 10:31 PM Qing Zhao wrote:
>>
>>
>>
>>> On Jun 4, 2024, at 03:43, Richard Biener wrote:
>>>
>>> On Mon, Jun 3, 2024 at 4:48 PM David Malcolm wrote:
>&g
> On Jun 5, 2024, at 13:07, Richard Biener wrote:
>
>
>
>> Am 05.06.2024 um 18:39 schrieb Qing Zhao :
>>
>>
>>
>>> On Jun 5, 2024, at 03:26, Richard Biener wrote:
>>>
>>>> On Tue, Jun 4, 2024 at 10:31 PM Qing Zhao wrote
> On Jun 5, 2024, at 09:49, David Malcolm wrote:
>
> On Tue, 2024-06-04 at 22:09 +0000, Qing Zhao wrote:
>>
>>
>>> On Jun 4, 2024, at 17:55, David Malcolm
>>> wrote:
>>>
>>> On Fri, 2024-05-31 at 13:11 +, Qing Zhao wrote:
>&g
Hi, Richard,
> On Jun 5, 2024, at 13:58, Qing Zhao wrote:
>>
>>>>>>>>> Like this?
>>>>>>>>>
>>>>>>>>> diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h
>>>>>>>>
more complicate testing case that has one
basic block copied multiple times by the jump thread, do you have any pointer
to such testing cases?
Thanks a lot for any help.
Qing
> On Jun 7, 2024, at 15:13, Qing Zhao wrote:
>
> Hi, Richard,
>
>> On Jun 5, 2024, at 13:5
tion pass.
diff --git a/gcc/copy-history-diagnostic-path.cc
b/gcc/copy-history-diagnostic-path.cc
new file mode 100644
index 000..65e5c056165
--- /dev/null
+++ b/gcc/copy-history-diagnostic-path.cc
@@ -0,0 +1,86 @@
+/* Classes for implementing diagnostic paths for copy_history_t.
+ Copyright (C
Hi, Martin,
I didn’t see your v3 patches attached to the email, did you miss them? (I
really want to see them -:).
> On Jul 15, 2024, at 16:58, Martin Uecker wrote:
>
> Am Montag, dem 15.07.2024 um 13:05 -0700 schrieb Kees Cook:
>> On Mon, Jul 15, 2024 at 07:20:31PM +0200, Martin Uecker wrote
> On Jul 15, 2024, at 17:41, Martin Uecker wrote:
>
> Am Montag, dem 15.07.2024 um 21:26 + schrieb Qing Zhao:
>> Hi, Martin,
>> I didn’t see your v3 patches attached to the email, did you miss them?
>> (I really want to see them -:).
>
> Sorry, I shoul
Hi, Martin,
I briefly reviewed these 4 patches this week.
Overall, I think that this is a nice new security feature to be added into gcc.
At the same time, I have the following questions about the patches:
1. Does the name of the option mismatch the description of the option?
-fvla-bounds
Em
Hi, Richard,
Could you please take a look at the patch and let me know any comment you have
(especially on the middle-end part)?
David, let me know if you have further comment and suggestions.
Thanks a lot.
Qing
> On Jul 12, 2024, at 10:03, Qing Zhao wrote:
>
> due to code du
The 2nd ping for the following patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657150.html
thanks.
Qing
> On Jul 22, 2024, at 09:01, Qing Zhao wrote:
>
> Hi, Richard,
>
> Could you please take a look at the patch and let me know any comment you
> have (especi
Hi, Kewen,
Thanks a lot for fixing this testing case issue.
Yes, the change LGTM though I can’t approve it.
Qing
> On Jul 31, 2024, at 05:22, Kewen.Lin wrote:
>
> Hi,
>
> As Andrew pointed out in PR116148, fam-in-union-alone-in-struct-2.c
> was designed for little-endian, the recent commit r
/* Functions to handle copy history.
+ Copyright (C) 2024-2024 Free Software Foundation, Inc.
+ Contributed by Qing Zhao
+
+ This file is part of GCC.
+
+ GCC is free software; you can redistribute it and/or modify it under
+ the terms of the GNU General Public License as published
> On Jul 2, 2024, at 18:02, David Malcolm wrote:
>
> On Tue, 2024-07-02 at 16:17 +0000, Qing Zhao wrote:
>> due to code duplication from jump threading [PR109071]
>> Control this with a new option -fdiagnostic-try-to-explain-harder.
>
> The name -fdiagnostic-tr
ssue with this solution.
thanks.
Qing
> On Nov 30, 2023, at 11:07 AM, Qing Zhao wrote:
>
> Hi,
>
> 1. For the following source code (portion):
>
> struct annotated {
> size_t foo;
> char b;
> char array[] __attribute__((counted_by (foo)));
> };
>
As discussed in PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48
We should explicitly document this limitation and issue error messages for C++.
The "counted_by" attribute currently is only supported in C, mention this
explicitly in documentation and also issue error when see "cou
> On Aug 5, 2024, at 09:53, Jakub Jelinek wrote:
>
> On Mon, Aug 05, 2024 at 01:33:01PM +0000, Qing Zhao wrote:
>> As discussed in
>> PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48
>>
>> We should explicitly document this limitation a
> On Aug 5, 2024, at 12:51, Jakub Jelinek wrote:
>
> On Mon, Aug 05, 2024 at 04:46:09PM +0000, Qing Zhao wrote:
>> So, you want me to add counted_by test-suite for C23? (Which should be
>> supported)
>> Okay, but I will do it in another separate patch since this
On Aug 5, 2024, at 13:54, Jakub Jelinek wrote:
On Mon, Aug 05, 2024 at 01:48:25PM -0400, Jason Merrill wrote:
On 8/5/24 9:53 AM, Jakub Jelinek wrote:
On Mon, Aug 05, 2024 at 01:33:01PM +, Qing Zhao wrote:
As discussed in PR116016:https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016#c48
We
On Aug 5, 2024, at 06:33, Martin Uecker wrote:
>
> Am Montag, dem 05.08.2024 um 11:50 +0200 schrieb Jakub Jelinek:
>> On Mon, Aug 05, 2024 at 11:45:56AM +0200, Alejandro Colomar wrote:
>>> [CC += Kees, Qing]
>>>
>>> Hi Joseph,
>>>
>>> On Sun, Aug 04, 2024 at 08:34:24PM GMT, Alejandro Colomar wr
Compared to the first version, the major changes are:
1. Changed the error as a warning with -Wattributes per Jakub and Jason's
comments.
2. Update documentation accordingly.
3. Move the testing case to g++.dg/ext
Add one more new testing case for C++11
Adjust the testing case according t
On Aug 5, 2024, at 16:59, Alejandro Colomar wrote:
The “counted-by” attribute currently is not in the TYPE system, and
we plan to add it into the TYPE system later through language
standard (or an GCC extension). If that happens, then both the
“sizeof” and the “__lengthof__” operators should
() =>
array_type_nelts_minus_one()
2: 2bb966a0a89 = 2: 2bb966a0a89 Merge definitions of array_type_nelts_top()
3: d22b5e1c015 ! 3: e2dbfc43b14 c: Add __lengthof__() operator
@@ Metadata
Author: Alejandro Colomar
## Commit message ##
-c: Add __lengthof__() operator
+c: Add _
Some comments on the documentation part.
(Hopefully, this time my quoting format is good, I checked the email
sent back to myself, no formatting issue, but when I checked the emails
in the archive,
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659593.html,
yst, I see the quoting forma
Hi, Kewen,
Thanks for the patch, LGTM.
Qing
> On Aug 9, 2024, at 05:50, Kewen.Lin wrote:
>
> Hi,
>
> As PR116148#c7 shows, fam-in-union-alone-in-struct-2.c still
> fails on hppa which is a BE environment, but by checking more
> (also confirmed by John in PR116148#c12), it's due to that
> si
:32, Qing Zhao wrote:
>
> The 2nd ping for the following patch:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2024-July/657150.html
>
> thanks.
>
> Qing
>
>> On Jul 22, 2024, at 09:01, Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>> Could you
Gentle ping on this simple patch.
thanks.
Qing
> On Aug 5, 2024, at 16:17, Qing Zhao wrote:
>
> Compared to the first version, the major changes are:
>
> 1. Changed the error as a warning with -Wattributes per Jakub and Jason's
> comments.
> 2. Update documentat
With the addition of the 'counted_by' attribute and its wide roll-out
within the Linux kernel, a use case has been found that would be very
nice to have for object allocators: being able to set the counted_by
counter variable without knowing its name.
For example, given:
struct foo {
...
> On Aug 13, 2024, at 17:05, Dimitar Dimitrov wrote:
>
> On Tue, Aug 13, 2024 at 07:34:09PM +0200, Hans-Peter Nilsson wrote:
>>> From: Sam James
>>> Date: Tue, 13 Aug 2024 18:17:29 +0100
>>
>>> Hans-Peter Nilsson writes:
>>>
I stumbled on this being a regression for cris-elf as well;
> On Aug 20, 2024, at 05:58, Richard Biener wrote:
>
> On Tue, Aug 13, 2024 at 5:34 PM Qing Zhao wrote:
>>
>> With the addition of the 'counted_by' attribute and its wide roll-out
>> within the Linux kernel, a use case has been found that would be very
te and its
consumers
Qing Zhao
11/06/2023
==
The whole discussion is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633783.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634844.html
1. The problem
There is a data dependency betwee
feature.
thanks.
Qing
> On Nov 6, 2023, at 7:12 PM, Qing Zhao wrote:
>
> Hi,
>
> Attached is the 2nd version of the proposal based on all the discussion so
> far.
>
> Let me know if you have more comment and suggestion.
>
> Thanks a l
> On Nov 9, 2023, at 11:50 AM, Jose Marchesi wrote:
>
>>
>> On Thu, Nov 09, 2023 at 03:49:49PM +, Qing Zhao wrote:
>>> Is it reasonable to add one option to disable the “counted_by” attribute?
>>> (then no insertion of the new .ACCESS_WITH_SIZE into
te and its
consumers
Qing Zhao
11/09/2023
==
The whole discussion is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/633783.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634844.html
https://gcc.gnu.org/pipermail/gcc-patches/202
Hi,
1. For the following source code (portion):
struct annotated {
size_t foo;
char b;
char array[] __attribute__((counted_by (foo)));
};
static void noinline bar ()
{
struct annotated *p2 = alloc_buf (10);
p2->array[8] = 0;
return;
}
2. I modified C FE to generate the following co
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
> On Jan 14, 2022, at 6:45 AM, Richard Biener
> wrote:
>
> On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote:
>>
>> Hi, Richard,
>>
>> This is the updated version for the second patch, which is mainly the change
>> for "Enable -Wuninitializ
> 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
>>> wrote:
>>>
>>> On Thu, Jan 13, 2022 at 2:45 AM Qing Zhao wrote:
>>>>
>>>> Hi,
he threshold is 3.
this value of the threshold can be adjusted by the new option:
--param builtin-string-cmp-inline-length=
The following is the patch.
thanks.
Qing
gcc/ChangeLog:
+2018-06-18 Qing Zhao
+
+ PR middle-end/78809
+ * builtins.c (expand_builtin_memcmp): Inlin
> On Jun 22, 2018, at 11:49 PM, Jeff Law wrote:
>
> On 05/29/2018 06:08 PM, Qing Zhao wrote:
>> Hi, Jeff,
>>
>> Thanks a lot for your review and comments.
>>
>> I have updated my patch based on your suggestion, and retested this whole
>> patch
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
Hi,
I’d like to ping the following patch the 2nd time:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01454.html
I already addressed all the issues raised for the first version of the patch,
and retested on both X86 and Aarch64, without any issue.
I’d really like to make it into GCC 8.
thank
Hi, Jeff,
Really sorry for my delay.
Your email on 1/12/2018 and Richard’s email on 1/15/2018, were completely
lost in my mailboxes until yesterday my colleague, Paolo Carlini, forwarded it
to me.
I really apologize for the late reply.
Please see my reply below:
> On Jan 12, 2018, at 4:
>
> We're now in stage4 so please queue this patch and ping it during
> next stage1.
>
I will update my patch based on Jeff and your comments, and send it during next
stage 1.
thanks.
Qing
Hi, this is the 3rd version for this patch.
the main change compared with 2nd version are:
1. do not use “compute_objsize” to get the minimum object size per Jeff
and Richard’s
comment. Instead, add a new function “determine_min_objsize” for this purpose.
This new
function calls “compute
Added myself as GCC maintainer with r255248:
https://gcc.gnu.org/ml/gcc-cvs/2017-11/msg00965.html
<https://gcc.gnu.org/ml/gcc-cvs/2017-11/msg00965.html>
thanks.
Qing
==
ChangeLog
+2017-11-29 Qing Zhao
+
+ * MAINTAINERS (Write After Approval): Add myself.
+
for trunk?
thanks.
Qing
gcc/fortran/ChangeLog
2017-11-30 Qing Zhao mailto:qing.z...@oracle.com>>
* fortran/decl.c (gfc_get_pdt_instance): Adjust the call to
sprintf to avoid the same buffer being both source and
=
gcc/ChangeLog
2017-11-30 Qing Zhao mailto:qing.z...@oracle.com>>
PR middle_end/79538
* gimple-fold.c (get_range_strlen): Add the handling of non-member array.
gcc/fortran/ChangeLog
2017-11-30 Qing Zhao mailto:qing.z...@oracl
Hi, Richard,
thanks a lot for your review.
>
>>{
>> /* __copy is always the same for characters.
>> Check to see if copy function already exists. */
>> - sprintf (name, "__copy_character_%d", ts->kind);
>> + na
> On Dec 12, 2017, at 10:50 AM, Richard Biener wrote:
>>>
+return false;
+ val = fold_build2 (MINUS_EXPR, TREE_TYPE (val), val,
+ integer_one_node);
>>>
>>> val = wide_int_to_tree (TREE_TYPE (val), wi::minus (wi::to_wi
Hi, Martin,
thanks for the suggestion, this might be a good enhancement for
get_range_strlen for a future work.
my understanding is, the current get_range_strlen does not use value range
info yet, and also does not handle VLA.
we can improve it from both aspects in a later work.
Qing
>>
>
ng:
gcc/ChangeLog
2017-12-13 Qing Zhao
PR middle_end/79538
* gimple-fold.c (get_range_strlen): Add the handling of non-member array.
gcc/fortran/ChangeLog
2017-12-13 Qing Zhao
PR middle_end/79538
* class.c (gfc_build_class_symbol): Replace call to
sprintf with xasp
> On Dec 14, 2017, at 2:05 AM, Richard Biener wrote:
>
> On Wed, 13 Dec 2017, Qing Zhao wrote:
>
>> Hi,
>>
>> I updated gimple-fold.c as you suggested, bootstrapped and re-tested on both
>> x86 and aarch64. no any issue.
>>
>>
>&
and tested on both X86 and Aarch64. no regression.
Okay for trunk?
thanks.
Qing
====
gcc/ChangeLog:
2017-12-11 Qing Zhao mailto:qing.z...@oracle.com>>
PR middle-end/78809
PR middle-end/83026
* tree-ssa-strlen.c (compute_string_length): New functio
> On Dec 14, 2017, at 1:36 PM, Jeff Law wrote:
>
> On 12/14/2017 12:22 PM, Qing Zhao wrote:
>>
>>> On Dec 14, 2017, at 2:05 AM, Richard Biener >> <mailto:rguent...@suse.de>> wrote:
>>>
>>> On Wed, 13 Dec 2017, Qing Zhao wrote:
>>
Hi, Jakub,
thanks a lot for your detailed review.
> On Dec 14, 2017, at 2:45 PM, Jakub Jelinek wrote:
>
> On Thu, Dec 14, 2017 at 01:45:21PM -0600, Qing Zhao wrote:
>> 2017-12-11 Qing Zhao mailto:qing.z...@oracle.com>>
>
> No " <mailto:qing.z...@oracl
> On Dec 15, 2017, at 10:42 AM, Jakub Jelinek wrote:
>
> On Fri, Dec 15, 2017 at 10:08:03AM -0600, Qing Zhao wrote:
>> a little confused here:
>>
>> in the current code:
>> . the first case is: result = strcmp() != 0
>> . the second c
> On Dec 15, 2017, at 11:47 AM, Jakub Jelinek wrote:
>
> On Fri, Dec 15, 2017 at 11:17:37AM -0600, Qing Zhao wrote:
>> HOST_WIDE_INT const_string_leni = -1;
>>
>> if (idx1)
>>{
>> const_string_leni = compute_string_length (idx1);
>>
Hi, Wilco,
thanks a lot for your review and comments.
> On Dec 15, 2017, at 6:41 AM, Wilco Dijkstra wrote:
>
> Hi Qing,
>
> Just looking at a very high level, I have a few comments:
>
> 1. Constant folding str(n)cmp - folding is done separately in
> fold-const-call.c
> and gimple-fold.c.
/ChangeLog:
+2017-12-21 Qing Zhao
+
+ PR middle-end/78809
+ PR middle-end/83026
+ * builtins.c (expand_builtin): Add the handling of BUILT_IN_STRCMP_EQ
+ and BUILT_IN_STRNCMP_EQ.
+ * builtins.def: Add new builtins BUILT_IN_STRCMP_EQ and
+ BUILT_IN_STRNCMP_EQ
301 - 400 of 1234 matches
Mail list logo
