On 08/17/2018 03:14 AM, Bernd Edlinger wrote:
> Hi!
>
>
> After the other patch has been applied, I re-based this patch accordingly.
>
> Except the mechanical changes, there are a few notable differences to the
> previous version:
>
> In string_constant, I added a similar check for the STRING_C
_strlen return then?
>>
>
> Yes, of course it is:
>
> $ cat y.c
> int f(char *x)
> {
>return __builtin_strlen(x);
> }
>
> int main ()
> {
>return f((char*)&L"abcdef"[0]);
> }
FWIW, I've twiddled this a bit and included it in Martin's patch for
86711/86714. THe proper return value is 0 or 1 depending on endianness.
Jeff
OK. So time to unstick 86711/86714.
I'm actually going to start by separating these two issues. While they
are related I think it's better to handle them as separate patches.
I also realize there's still ongoing work to change some of the
STRING_CST semantics. If that work r
On 08/25/18 22:42, Martin Sebor wrote:
> On 08/25/2018 01:32 PM, Bernd Edlinger wrote:
>> On 08/25/18 21:02, Jeff Law wrote:
>>> On 08/25/2018 12:36 PM, Bernd Edlinger wrote:
>>>
>>>
>>
>> Well, ya call it "layer one patch over the other"
>> I call it "incremental improvements".
>>>
On 08/25/2018 01:32 PM, Bernd Edlinger wrote:
> On 08/25/18 21:02, Jeff Law wrote:
>> On 08/25/2018 12:36 PM, Bernd Edlinger wrote:
>>
>>
>
> Well, ya call it "layer one patch over the other"
> I call it "incremental improvements".
It is (of course) a case by case basis. The w
On 08/25/2018 01:32 PM, Bernd Edlinger wrote:
On 08/25/18 21:02, Jeff Law wrote:
On 08/25/2018 12:36 PM, Bernd Edlinger wrote:
Well, ya call it "layer one patch over the other"
I call it "incremental improvements".
It is (of course) a case by case basis. The way I try to look at these
thi
On 08/25/18 21:02, Jeff Law wrote:
> On 08/25/2018 12:36 PM, Bernd Edlinger wrote:
>
>
Well, ya call it "layer one patch over the other"
I call it "incremental improvements".
>>> It is (of course) a case by case basis. The way I try to look at these
>>> things is to ask whether
On 08/25/2018 12:36 PM, Bernd Edlinger wrote:
>>>
>>> Well, ya call it "layer one patch over the other"
>>> I call it "incremental improvements".
>> It is (of course) a case by case basis. The way I try to look at these
>> things is to ask whether or not the first patch under consideration
>
On 08/25/18 19:32, Jeff Law wrote:
> On 08/25/2018 12:32 AM, Bernd Edlinger wrote:
>> On 08/25/18 01:54, Jeff Law wrote:
>>> On 08/24/2018 11:26 AM, Bernd Edlinger wrote:
On 08/24/18 18:51, Jeff Law wrote:
>> Well, this is broken for wide character strings.
>> but I hope we can get rid
On 08/25/2018 12:32 AM, Bernd Edlinger wrote:
> On 08/25/18 01:54, Jeff Law wrote:
>> On 08/24/2018 11:26 AM, Bernd Edlinger wrote:
>>> On 08/24/18 18:51, Jeff Law wrote:
> Well, this is broken for wide character strings.
> but I hope we can get rid of STRING_CST which are
> not explici
On 08/25/18 01:54, Jeff Law wrote:
> On 08/24/2018 11:26 AM, Bernd Edlinger wrote:
>> On 08/24/18 18:51, Jeff Law wrote:
Well, this is broken for wide character strings.
but I hope we can get rid of STRING_CST which are
not explicitly null terminated.
>>
>> I am afraid that is not go
On 08/24/2018 11:26 AM, Bernd Edlinger wrote:
> On 08/24/18 18:51, Jeff Law wrote:
>>> Well, this is broken for wide character strings.
>>> but I hope we can get rid of STRING_CST which are
>>> not explicitly null terminated.
>
> I am afraid that is not going to happen.
> Maybe we can get STRING_C
On 08/24/18 18:04, Jeff Law wrote:
> On 08/24/2018 06:27 AM, Bernd Edlinger wrote:
> [ Lots of snipping throughout ]
>
>
> +
> if (TREE_CODE (src) == COND_EXPR
> && (only_value || !TREE_SIDE_EFFECTS (TREE_OPERAND (src, 0
>{
> - tree len1, le
t; but I hope we can get rid of STRING_CST which are
>> not explicitly null terminated.
I am afraid that is not going to happen.
Maybe we can get STRING_CST that are never longer
than the TYPE_UNIT_SIZE, but c_strlen and c_getstr
need to take care that the string is zero-terminated.
string_cons
On 08/02/2018 07:26 AM, Bernd Edlinger wrote:
>
>> - if (compare_tree_int (array_size, length + 1) < 0)
>> + if (nulterm)
> but here you compare bytes with length which is measued un chars.
>
>> +*nulterm = array_elts > length;
>> + else if (array_elts <= length)
>> return NULL_TREE;
On 08/24/2018 06:27 AM, Bernd Edlinger wrote:
[ Lots of snipping throughout ]
>>>
+
if (TREE_CODE (src) == COND_EXPR
&& (only_value || !TREE_SIDE_EFFECTS (TREE_OPERAND (src, 0
{
- tree len1, len2;
-
- len1 = c_strlen (TREE_OPERAND
On 08/24/18 08:36, Jeff Law wrote:
> On 08/02/2018 07:26 AM, Bernd Edlinger wrote:
>> On 08/02/18 04:44, Martin Sebor wrote:
>>> Since the foundation of the patch is detecting and avoiding
>>> the overly aggressive folding of unterminated char arrays,
>>> besides issuing a warning for such argument
On Wed, Aug 15, 2018 at 5:42 PM Jeff Law wrote:
>
> On 08/15/2018 08:47 AM, Martin Sebor wrote:
> > On 08/15/2018 12:02 AM, Jeff Law wrote:
> >> On 08/13/2018 03:23 PM, Martin Sebor wrote:
> >>> To make reviewing the changes easier I've split up the patch
> >>> into a series:
> >> [ ... ]
> >> I'm
On 08/02/2018 07:26 AM, Bernd Edlinger wrote:
> On 08/02/18 04:44, Martin Sebor wrote:
>> Since the foundation of the patch is detecting and avoiding
>> the overly aggressive folding of unterminated char arrays,
>> besides issuing a warning for such arguments to strlen,
>> the patch also fixes pr86
>
>> Also the rest of the string length checks are refined, to return
>> actually zero-terminated single byte strings when strlen is not given,
>> and return something not necessarily zero-terminated which is
>> suitable for memxxx-functions otherwise.
>
>>
>&
terminated single byte strings when strlen is not given,
> and return something not necessarily zero-terminated which is
> suitable for memxxx-functions otherwise.
>
>
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
Not yet. There's a lot to go over here and I haven't finished reviewing
all the discussions around 86711/86714.
Jeff
ted const arrays (PR
86711, 86714)
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00769.html
and the strlen missing nul detection in part 2:
[PATCH 2/6] detect unterminated const arrays in strlen calls
(PR 86552)
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00778.html
The rest of the series (pa
Hi!
After the other patch has been applied, I re-based this patch accordingly.
Except the mechanical changes, there are a few notable differences to the
previous version:
In string_constant, I added a similar check for the STRING_CSTs
because when callers don't use mem_size, they assume to be
a
On 08/01/2018 08:44 PM, Martin Sebor wrote:
> Since the foundation of the patch is detecting and avoiding
> the overly aggressive folding of unterminated char arrays,
> besides issuing a warning for such arguments to strlen,
> the patch also fixes pr86711 - wrong folding of memchr, and
> pr86714 -
On 08/15/2018 08:47 AM, Martin Sebor wrote:
> On 08/15/2018 12:02 AM, Jeff Law wrote:
>> On 08/13/2018 03:23 PM, Martin Sebor wrote:
>>> To make reviewing the changes easier I've split up the patch
>>> into a series:
>> [ ... ]
>> I'm about done for the night and thus won't get into the series (and
On 08/15/2018 12:02 AM, Jeff Law wrote:
On 08/13/2018 03:23 PM, Martin Sebor wrote:
To make reviewing the changes easier I've split up the patch
into a series:
[ ... ]
I'm about done for the night and thus won't get into the series (and as
you know Bernd has a competing patch in this space). B
On 08/13/2018 03:23 PM, Martin Sebor wrote:
> To make reviewing the changes easier I've split up the patch
> into a series:
[ ... ]
I'm about done for the night and thus won't get into the series (and as
you know Bernd has a competing patch in this space). But I did want to
chime in on two things.
On 08/03/2018 03:38 PM, Bernd Edlinger wrote:
> On 08/03/18 23:15, Jeff Law wrote:
>> On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
>>> On 07/30/18 21:52, Martin Sebor wrote:
On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
> On 07/30/18 01:05, Martin Sebor wrote:
>> On 07/29/2018 04:56 A
On 08/03/2018 03:28 PM, Jakub Jelinek wrote:
> On Fri, Aug 03, 2018 at 03:16:41PM -0600, Jeff Law wrote:
>> On 07/31/2018 12:33 AM, Jakub Jelinek wrote:
>>> On Mon, Jul 30, 2018 at 10:01:38PM -0600, Martin Sebor wrote:
> We do not want to change what is currently accepted by the
> front end
On 08/03/2018 07:00 AM, Bernd Edlinger wrote:
> On 08/02/18 22:34, Martin Sebor wrote:
>> On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
>>> On 08/02/18 15:26, Bernd Edlinger wrote:
>
> /* If the length can be computed at compile-time, return it. */
> - len = c_strlen (src, 0);
On 08/13/18 16:27, Martin Sebor wrote:
> As I said below, the patch for PR 86552, 86711, 86714 that
> was first posted on July 19 fixes both of these issues and
> also diagnoses calls with unterminated strings:
>
> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00155.html
>
The attached changes implement the detection of nul-terminated
constant arrays and incorrect or early folding of such arrays.
This resolves PR 86711 - wrong folding of memchr, and prevents
PR 86714 - tree-ssa-forwprop.c confused by too long initializer.
No warnings are issued.
PR tree-optimization
To make reviewing the changes easier I've split up the patch
into a series:
1. Detection of nul-terminated constant arrays to prevent early
folding. This resolves PR 86711 - wrong folding of memchr,
and prevents PR 86714 - tree-ssa-forwprop.c confused by too
long initializer, but doesn'
As I said below, the patch for PR 86552, 86711, 86714 that
was first posted on July 19 fixes both of these issues and
also diagnoses calls with unterminated strings:
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg00155.html
On 08/12/2018 03:06 AM, Bernd Edlinger wrote:
Hi,
I'd like to
Hi,
I'd like to ping for this patch:
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01800.html
I will add a new BZ entry for the (minor) regression this patch
introduces in gcc.dg/strlenopt-49.c and assign it to myself.
Thanks
Bernd.
On 07/29/18 12:56, Bernd Edlinger wrote:
> Hi!
>
> This fix
On 08/03/18 23:15, Jeff Law wrote:
> On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
>> On 07/30/18 21:52, Martin Sebor wrote:
>>> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
On 07/30/18 01:05, Martin Sebor wrote:
> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> Thi
On Fri, Aug 03, 2018 at 03:16:41PM -0600, Jeff Law wrote:
> On 07/31/2018 12:33 AM, Jakub Jelinek wrote:
> > On Mon, Jul 30, 2018 at 10:01:38PM -0600, Martin Sebor wrote:
> >>> We do not want to change what is currently accepted by the
> >>> front end. period.
> >>
> >> On whose behalf are you maki
On 07/30/2018 01:52 PM, Martin Sebor wrote:
> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
>> On 07/30/18 01:05, Martin Sebor wrote:
>>> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants.
On 07/31/2018 12:33 AM, Jakub Jelinek wrote:
> On Mon, Jul 30, 2018 at 10:01:38PM -0600, Martin Sebor wrote:
>>> We do not want to change what is currently accepted by the
>>> front end. period.
>>
>> On whose behalf are you making such categorical statements?
>> It was Jakub and Richard's suggesti
On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
> On 07/30/18 21:52, Martin Sebor wrote:
>> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
>>> On 07/30/18 01:05, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
> Hi!
>
> This fixes two wrong code bugs where string_con
On 08/03/2018 07:00 AM, Bernd Edlinger wrote:
On 08/02/18 22:34, Martin Sebor wrote:
On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
On 08/02/18 15:26, Bernd Edlinger wrote:
/* If the length can be computed at compile-time, return it. */
- len = c_strlen (src, 0);
+ tree array;
+ tree le
On 08/02/18 22:34, Martin Sebor wrote:
> On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
>> On 08/02/18 15:26, Bernd Edlinger wrote:
/* If the length can be computed at compile-time, return it. */
- len = c_strlen (src, 0);
+ tree array;
+ tree len = c_strlen (src, 0,
On 08/02/2018 12:56 PM, Bernd Edlinger wrote:
On 08/02/18 15:26, Bernd Edlinger wrote:
/* If the length can be computed at compile-time, return it. */
- len = c_strlen (src, 0);
+ tree array;
+ tree len = c_strlen (src, 0, &array);
You know the c_strlen tries to compute wide character
On 08/02/18 15:26, Bernd Edlinger wrote:
>>
>> /* If the length can be computed at compile-time, return it. */
>> - len = c_strlen (src, 0);
>> + tree array;
>> + tree len = c_strlen (src, 0, &array);
>
> You know the c_strlen tries to compute wide character sizes,
> but strlen does not do
On 08/02/18 04:44, Martin Sebor wrote:
> Since the foundation of the patch is detecting and avoiding
> the overly aggressive folding of unterminated char arrays,
> besides issuing a warning for such arguments to strlen,
> the patch also fixes pr86711 - wrong folding of memchr, and
> pr86714 - tree-
Since the foundation of the patch is detecting and avoiding
the overly aggressive folding of unterminated char arrays,
besides issuing a warning for such arguments to strlen,
the patch also fixes pr86711 - wrong folding of memchr, and
pr86714 - tree-ssa-forwprop.c confused by too long initializer.
On Mon, Jul 30, 2018 at 10:01:38PM -0600, Martin Sebor wrote:
> > We do not want to change what is currently accepted by the
> > front end. period.
>
> On whose behalf are you making such categorical statements?
> It was Jakub and Richard's suggestion in bug 86714 to reject
> the undefined excessi
On 07/30/2018 02:21 PM, Bernd Edlinger wrote:
On 07/30/18 21:52, Martin Sebor wrote:
On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
On 07/30/18 01:05, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length
On 07/30/18 21:52, Martin Sebor wrote:
> On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
>> On 07/30/18 01:05, Martin Sebor wrote:
>>> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Init
On 07/30/2018 09:24 AM, Bernd Edlinger wrote:
On 07/30/18 01:05, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
If by
On 07/30/18 01:05, Martin Sebor wrote:
> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> This fixes two wrong code bugs where string_constant
>> returns over length string constants. Initializers
>> like that are rejected in C++, but valid in C.
>
> If by valid you are referring to dec
On 07/30/2018 12:57 AM, Richard Biener wrote:
On Sun, 29 Jul 2018, Martin Sebor wrote:
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
If
On Sun, 29 Jul 2018, Martin Sebor wrote:
> On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
> > Hi!
> >
> > This fixes two wrong code bugs where string_constant
> > returns over length string constants. Initializers
> > like that are rejected in C++, but valid in C.
>
> If by valid you are referri
On 07/29/2018 04:56 AM, Bernd Edlinger wrote:
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
If by valid you are referring to declarations like the one in
the added test:
const cha
Hi!
This fixes two wrong code bugs where string_constant
returns over length string constants. Initializers
like that are rejected in C++, but valid in C.
I have xfailed strlenopt-49.c, which tests this feature.
Personally I don't think that it is worth the effort to
optimize something that is p
55 matches
Mail list logo
