On 07/24/2018 02:16 PM, Martin Sebor wrote:
> On 07/20/2018 04:20 AM, Richard Biener wrote:
>> On Thu, 19 Jul 2018, Martin Sebor wrote:
>>
>>> Here's one more update with tweaks addressing a couple more
>>> of Bernd's comments:
>>>
>>> 1) correct the use of TREE_STRING_LENGTH() where a number of
>>
On 07/20/2018 04:20 AM, Richard Biener wrote:
On Thu, 19 Jul 2018, Martin Sebor wrote:
Here's one more update with tweaks addressing a couple more
of Bernd's comments:
1) correct the use of TREE_STRING_LENGTH() where a number of
array elements is expected and not bytes
2) set CHARTYPE as soon
On July 23, 2018 7:46:08 PM GMT+02:00, Martin Sebor wrote:
>On 07/23/2018 02:05 AM, Jakub Jelinek wrote:
>> On Sun, Jul 22, 2018 at 04:47:45PM -0600, Martin Sebor wrote:
No, I mean something like:
$ cat y.c
const char a[2][3] = { "1234", "xyz" };
char b[6];
int m
On 07/23/2018 02:05 AM, Jakub Jelinek wrote:
On Sun, Jul 22, 2018 at 04:47:45PM -0600, Martin Sebor wrote:
No, I mean something like:
$ cat y.c
const char a[2][3] = { "1234", "xyz" };
char b[6];
int main ()
{
__builtin_memcpy(b, a, 4);
__builtin_memset(b + 4, 'a', 2);
__builtin_printf
On Sun, Jul 22, 2018 at 04:47:45PM -0600, Martin Sebor wrote:
> > No, I mean something like:
> >
> > $ cat y.c
> > const char a[2][3] = { "1234", "xyz" };
> > char b[6];
> >
> > int main ()
> > {
> >__builtin_memcpy(b, a, 4);
> >__builtin_memset(b + 4, 'a', 2);
> >__builtin_printf("%.
On 07/22/2018 04:47 PM, Martin Sebor wrote:
On 07/22/2018 02:00 AM, Bernd Edlinger wrote:
On 07/21/18 00:15, Martin Sebor wrote:
On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
if (s
On 07/22/2018 03:03 AM, Bernd Edlinger wrote:
On 07/21/18 01:58, Martin Sebor wrote:
On 07/20/2018 03:11 PM, Bernd Edlinger wrote:
I think I have found a valid test case where the latest patch
does generate invalid code:
This is due to another bug in string_constant() that's latent
on trunk b
On 07/22/2018 02:00 AM, Bernd Edlinger wrote:
On 07/21/18 00:15, Martin Sebor wrote:
On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
if (str1 == NULL_TREE)
break;
On 07/21/18 01:58, Martin Sebor wrote:
> On 07/20/2018 03:11 PM, Bernd Edlinger wrote:
>> I think I have found a valid test case where the latest patch
>> does generate invalid code:
>
> This is due to another bug in string_constant() that's latent
> on trunk but that's exposed by the patch. Trun
On 07/21/18 00:15, Martin Sebor wrote:
> On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
>> Martin,
>>
>> when I look at tree-ssa-forwprop.c:
>>
>> str1 = string_constant (src1, &off1);
>> if (str1 == NULL_TREE)
>> break;
>> if (!tree_fits
On 07/20/2018 03:11 PM, Bernd Edlinger wrote:
I think I have found a valid test case where the latest patch
does generate invalid code:
This is due to another bug in string_constant() that's latent
on trunk but that's exposed by the patch. Trunk only "works"
because of a bug/limitation in c_st
On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
if (str1 == NULL_TREE)
break;
if (!tree_fits_uhwi_p (off1)
|| compare_tree_int (off1,
I think I have found a valid test case where the latest patch
does generate invalid code:
$ cat part.c
static const char a[3][8] = { "1234", "12345", "123456" };
int main ()
{
volatile int i = 1;
int n = __builtin_strlen (*(&a[1]+i));
if (n != 6)
__builtin_abort ();
}
$ gcc part.c
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, &off1);
if (str1 == NULL_TREE)
break;
if (!tree_fits_uhwi_p (off1)
|| compare_tree_int (off1, TREE_STRING_LENGTH (str1) - 1) > 0
On Thu, 19 Jul 2018, Martin Sebor wrote:
> Here's one more update with tweaks addressing a couple more
> of Bernd's comments:
>
> 1) correct the use of TREE_STRING_LENGTH() where a number of
> array elements is expected and not bytes
> 2) set CHARTYPE as soon as it's first determined rather than
> if (TREE_CODE (arg) == ADDR_EXPR)
> {
>+ tree argtype = TREE_TYPE (arg);
>+ chartype = argtype;
This assignment should be unnecessary here. Right?
>+
> arg = TREE_OPERAND (arg, 0);
> tree ref = arg;
> if (TREE_CODE (arg) == ARRAY_REF)
> {
> tree
>@@ -605,14 +605,21 @@ c_strlen (tree src, int only_value)
>
> /* Set MAXELTS to sizeof (SRC) / sizeof (*SRC) - 1, the maximum possible
> length of SRC. Prefer TYPE_SIZE() to TREE_STRING_LENGTH() if possible
>- in case the latter is less than the size of the array. */
>- HOST_WIDE_IN
On 07/19/2018 02:45 PM, Bernd Edlinger wrote:
@@ -11413,8 +11429,10 @@ string_constant (tree arg, tree *ptr_offset)
const char a[4] = "abc\000\000";
The excess elements contribute to TREE_STRING_LENGTH()
but not to strlen(). */
- unsigned HOST_WIDE_INT length
-= strnlen (TREE
Here's one more update with tweaks addressing a couple more
of Bernd's comments:
1) correct the use of TREE_STRING_LENGTH() where a number of
array elements is expected and not bytes
2) set CHARTYPE as soon as it's first determined rather than
trying to extract it again later
On 07/19/2018 01:49
>@@ -11413,8 +11429,10 @@ string_constant (tree arg, tree *ptr_offset)
> const char a[4] = "abc\000\000";
> The excess elements contribute to TREE_STRING_LENGTH()
> but not to strlen(). */
>- unsigned HOST_WIDE_INT length
>-= strnlen (TREE_STRING_POINTER (init), TREE_STRING_LEN
On 07/19/18 22:03, Martin Sebor wrote:
> On 07/19/2018 07:23 AM, Bernd Edlinger wrote:
>>> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
>>> return ssize_int (0);
>>>
>>> /* We don't know the starting offset, but we do know that the string
>>> - has no internal zero byte
On 07/19/2018 07:23 AM, Bernd Edlinger wrote:
@@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
return ssize_int (0);
/* We don't know the starting offset, but we do know that the string
-has no internal zero bytes. We can assume that the offset falls
-wit
On 07/19/2018 12:19 AM, Bernd Edlinger wrote:
if (TREE_CODE (idx) != INTEGER_CST
&& TREE_CODE (argtype) == POINTER_TYPE)
{
/* From a pointer (but not array) argument extract the variable
index to prevent get_addr_base_and_unit_off
On 07/19/2018 01:17 AM, Richard Biener wrote:
On Wed, 18 Jul 2018, Martin Sebor wrote:
+ while (TREE_CODE (chartype) != INTEGER_TYPE)
+chartype = TREE_TYPE (chartype);
This is a bit concerning. First under what conditions is chartype not
going to be an INTEGER_TYPE? And under what c
> @@ -633,12 +642,17 @@ c_strlen (tree src, int only_value)
> return ssize_int (0);
>
>/* We don't know the starting offset, but we do know that the string
> - has no internal zero bytes. We can assume that the offset falls
> - within the bounds of the string; otherwise,
On Wed, 18 Jul 2018, Martin Sebor wrote:
> > > > + while (TREE_CODE (chartype) != INTEGER_TYPE)
> > > > +chartype = TREE_TYPE (chartype);
> > > This is a bit concerning. First under what conditions is chartype not
> > > going to be an INTEGER_TYPE? And under what conditions will extract
if (TREE_CODE (idx) != INTEGER_CST
&& TREE_CODE (argtype) == POINTER_TYPE)
{
/* From a pointer (but not array) argument extract the variable
index to prevent get_addr_base_and_unit_offset() from failing
due to it.
+ while (TREE_CODE (chartype) != INTEGER_TYPE)
+chartype = TREE_TYPE (chartype);
This is a bit concerning. First under what conditions is chartype not
going to be an INTEGER_TYPE? And under what conditions will extracting
its type ultimately lead to something that is an INTEGER_TYPE?
On 07/18/2018 02:31 AM, Richard Biener wrote:
On Tue, 17 Jul 2018, Martin Sebor wrote:
The attached update takes care of a couple of problems pointed
out by Bernd Edlinger in his comments on the bug. The ICE he
mentioned in comment #20 was due mixing sizetype, ssizetype,
and size_type_node in
On Tue, 17 Jul 2018, Martin Sebor wrote:
> The attached update takes care of a couple of problems pointed
> out by Bernd Edlinger in his comments on the bug. The ICE he
> mentioned in comment #20 was due mixing sizetype, ssizetype,
> and size_type_node in c_strlen(). AFAICS, some of it predates
The attached update takes care of a couple of problems pointed
out by Bernd Edlinger in his comments on the bug. The ICE he
mentioned in comment #20 was due mixing sizetype, ssizetype,
and size_type_node in c_strlen(). AFAICS, some of it predates
the patch but my changes made it worse and also m
On 07/17/2018 09:38 AM, Jeff Law wrote:
On 07/17/2018 09:19 AM, Martin Sebor wrote:
My enhancement to extract constant strings out of complex
aggregates committed last week introduced a couple of bugs in
dealing with non-constant indices and offsets. One of the bugs
was fixed earlier today (PR
On 07/17/2018 09:19 AM, Martin Sebor wrote:
> My enhancement to extract constant strings out of complex
> aggregates committed last week introduced a couple of bugs in
> dealing with non-constant indices and offsets. One of the bugs
> was fixed earlier today (PR 86528) but another one remains. It
My enhancement to extract constant strings out of complex
aggregates committed last week introduced a couple of bugs in
dealing with non-constant indices and offsets. One of the bugs
was fixed earlier today (PR 86528) but another one remains. It
causes strlen (among other functions) to incorrect
34 matches
Mail list logo
