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, );
>>
>> You know the c_strlen tries to
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
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
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
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
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
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
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
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,
On 08/24/18 18:51, Jeff Law wrote:
> 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
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
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
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
On 08/16/2018 11:14 PM, Jeff Law wrote:
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
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/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/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
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, );
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, );
>
> You know the c_strlen tries to compute wide character sizes,
> but strlen does not do that,
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 -
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
25 matches
Mail list logo
