On Sat, Jul 7, 2018 at 11:47 PM Martin Sebor <mse...@gmail.com> wrote: > > While working on other string folding improvements (PR 77357) > I came across another distinct case where GCC could do better: > it doesn't consider as candidates strings that have as many > elements as the size of the array they are stored in, even if > their length is within the bounds of the array. For instance, > only the first strlen() call below is folded even though > the arguments to both are valid NUL-terminated strings. > > const char a[4] = "123"; > int f (void) > { > return strlen (a); // folded > } > > const char b[4] = "123\0"; > int g (void) > { > return strlen (b); // not folded > } > > The attached tiny patch adjusts the the string_constant() function > to recognize as valid string constants all those whose length (as > returned by strlen()) is less than the size of the array they are > stored in. > > Tested on x86_64-linux. > > Testing of an earlier version of the patch exposed what I think > is a deficiency in the (very) early strlen folding: c_strlen() > folds expressions of the form strlen(A + I) to sizeof(A) - I when > A is an array of known size and I a non-const variable. This not > only prevents -Warray-bounds from warning on invalid indices but > also defeats other, possibly more profitable optimizations based > on the range of the result of the strlen() call. The logs show > that the code dates at least as far back as 1992. With VRP and > other data flow based optimizations I think we can do better > today. I opened bug 86434 to improve things.
I think that + unsigned HOST_WIDE_INT length = strlen (TREE_STRING_POINTER (init)); is dangerous and you should use strnlen (TREE_STRING_POINTER (init), TREE_STRING_LENGTH (init)) instead. OK with that change. Richard. > Martin >