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
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);
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);
> >
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, );
if (str1
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
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, );
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.
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, );
>> if (str1 == NULL_TREE)
>> break;
>> if
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
On 07/20/2018 08:51 AM, Bernd Edlinger wrote:
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, );
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 (*([1]+i));
if (n != 6)
__builtin_abort ();
}
$ gcc part.c
Martin,
when I look at tree-ssa-forwprop.c:
str1 = string_constant (src1, );
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. */
>-
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
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
>@@ -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),
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
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
-
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
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
> @@ -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
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
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.
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
34 matches
Mail list logo
