https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #29 from Martin Sebor ---
Author: msebor
Date: Wed Jul 25 02:11:31 2018
New Revision: 262958
URL: https://gcc.gnu.org/viewcvs?rev=262958=gcc=rev
Log:
PR tree-optimization/86622 - incorrect strlen of array of array plus variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #28 from Bernd Edlinger ---
Yes, agreed.
Should I send a patch to take out the statement in comment #17,
or will you do that in your follow-up patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #27 from Martin Sebor ---
I don't think it would be appropriate to introduce dependencies on the
sanitizer for the same reason we can't do that for warnings. But as I
mentioned in comment 16, I think performing these sorts of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #26 from Bernd Edlinger ---
../../gcc-9-20180715-1/gcc/expr.c:11360 is:
while (TREE_CODE (chartype) != INTEGER_TYPE)
chartype = TREE_TYPE (chartype);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #25 from Bernd Edlinger ---
Sorry again Martin,
but with the latest patch I see the following:
FAIL: gcc.target/i386/avx-vdppd-2.c (internal compiler error)
FAIL: gcc.target/i386/avx-vdppd-2.c (test for excess errors)
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #24 from Bernd Edlinger ---
Hope you don't mind, but may I suggest to do the comparison in unsigned
arithmetics, like:
/* We don't know the starting offset, but we do know that the string
has no internal zero bytes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #23 from Bernd Edlinger ---
Aehm, and won't this kind of folding make it impossible
for asan/ubsan to spot the bug?
I mean why not make that dependent on the sanitizer?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #22 from Bernd Edlinger ---
(In reply to Martin Sebor from comment #21)
> Thanks for testing the patch! I've tweaked it to avoid the ICE. I'm not
> sure what masked the ICE in my testing but mixing signed and unsigned types
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #21 from Martin Sebor ---
Thanks for testing the patch! I've tweaked it to avoid the ICE. I'm not sure
what masked the ICE in my testing but mixing signed and unsigned types in the
same expression without conversion was the cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #20 from Bernd Edlinger ---
part.c.004t.original looks funny:
;; Function main (null)
;; enabled by -tree-original
{
volatile int i = 4;
int n = 4;
volatile int i = 4;
int n = 4;
SAVE_EXPR <= 4 ? 4 - (ssizetype)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #19 from Bernd Edlinger ---
sorry wrong test case:
$ cat part.c
cat part.c
#define a "121\01"
int main ()
{
volatile int i=4;
int n = __builtin_strlen ([0]);
n += __builtin_strlen ([i]);
if (n != 4)
__builtin_abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #18 from Bernd Edlinger ---
(In reply to Martin Sebor from comment #12)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00936.html
Sorry, Martin,
with your patch I have an ICE in the following test:
$ cat part.c
const char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #17 from Bernd Edlinger ---
Martin,
in expr.c at string_constant() there is an impossible check:
if (TREE_CODE (init) == CONSTRUCTOR)
{
if (TREE_CODE (arg) != ARRAY_REF
&& TREE_CODE (arg) == COMPONENT_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #16 from Martin Sebor ---
I would prefer to avoid discussing the array size rule and optimization in too
many places, and especially in bugs that aren't directly related to it. There
are other bugs where it is being discussed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #14 from Bernd Edlinger ---
(In reply to Martin Sebor from comment #13)
> (In reply to Richard Biener from comment #9)
> >
> > I bet Martin would argue it's invalid ...
>
> That's right, the example in comment 8 is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #13 from Martin Sebor ---
(In reply to Richard Biener from comment #9)
>
> I bet Martin would argue it's invalid ...
That's right, the example in comment 8 is undefined because strlen() requires a
nul-terminated string argument and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #12 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #11 from Bernd Edlinger ---
But seriously:
/* Avoid returning a string that doesn't fit in the array
it is stored in, like
const char a[4] = "abcde";
but do handle those that fit even if they have excess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #10 from Bernd Edlinger ---
(In reply to Richard Biener from comment #9)
>
> I bet Martin would argue it's invalid ...
>
> The standard specifies initializing char[3] with "121" is valid. 7.24.1/1
> specifies "if an array is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #9 from Richard Biener ---
(In reply to Bernd Edlinger from comment #8)
> $ cat part.c
>
> const char a[2][3] = { "121", "1" };
>
> int main ()
> {
> int n = __builtin_strlen ([0][0]);
> n += __builtin_strlen (a[0]);
>
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #8 from Bernd Edlinger ---
$ cat part.c
const char a[2][3] = { "121", "1" };
int main ()
{
int n = __builtin_strlen ([0][0]);
n += __builtin_strlen (a[0]);
if (n != 8)
__builtin_abort ();
}
I think I find no way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #7 from Bernd Edlinger ---
Maybe something like the following?
--- expr.c.kk 2018-07-17 10:14:43.668347058 +0200
+++ expr.c 2018-07-17 10:21:13.101779984 +0200
@@ -11282,6 +11282,7 @@ string_constant (tree arg, tree *ptr_off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #6 from Bernd Edlinger ---
const char a[2][3] = { "1234", "12" };
int main ()
{
{
volatile int i = 1;
int n = __builtin_strlen (a[i]);
n += __builtin_strlen (a[0]);
if (n != 3)
__builtin_abort ();
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #5 from Bernd Edlinger ---
FYI the patch for pr85528 does not contain the hunk from comment #3
I think it is probably more restrictive than necessary.
Happy hacking!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #3 from Bernd Edlinger ---
Hi Martin,
how about:
--- gcc/expr.c.jj 2018-07-09 22:33:48.0 +0200
+++ gcc/expr.c 2018-07-16 17:18:47.919177047 +0200
@@ -11359,6 +11359,9 @@ string_constant (tree arg, tree *ptr_off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
31 matches
Mail list logo
