https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63989
--- Comment #2 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 20 Nov 2014, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63989 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEW > Last reconfirmed| |2014-11-20 > Ever confirmed|0 |1 > > --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > So, we are talking here about e.g. > > int > f1 (char *p) > { > __builtin_strcpy (p, "foobar"); > return __builtin_strlen (p + 2); > } > > int > f2 (char *p) > { > __builtin_strcpy (p, "foobar"); > p[2] = '\0'; > return __builtin_strlen (p); > } > > int > f3 (char *p) > { > __builtin_strcpy (p, "foobar"); > p[2] = '\0'; > return __builtin_strlen (p + 3); > } > > int > f4 (char *p) > { > __builtin_strcpy (p, "foobar"); > p[2] = 'z'; > return __builtin_strlen (p); > } > > and then also determining using get_string_length (if constant) whether a > character pointer dereference is known to be zero or known to be non-zero. Well, we are mainly talking about the case where I had to XFAIL gcc.dg/strlenopt-8.c for us now inline-expanding a two-character memcpy to a short store.
