[Bug middle-end/71625] missing strlen optimization on different array initialization style

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71625

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #4)
> I'm working on a patch that among other things transforms the CONSTRUCTOR
> node created for an array initializer to STRING_CST, as suggested by Richard
> in bug 71303 that this one is a duplicate of, to help fold strlen results
> for constant arguments (this also affects C++ constexpr where it would be
> useful to be able to call strlen).  Let me confirm this one since it has
> more discussion and close the other as a dupe.

That will be certainly useful not just for this, but also for the generated
code quality if it can't/shouldn't be optimized into constant (the usual case).

But,
int baz ()
{
  char a[4];
  a[0] = 'a';
  a[1] = 'b';
  a[2] = 'c';
  a[3] = '\0';
  return __builtin_strlen (a); 
}
still won't be optimized.  Not sure if it is worth to do something about it
though.  It can as well have the form
int baz2 ()
{
  char a[30];
  __builtin_memcpy (a, "1234567", 7);
  __builtin_memcpy (a + 7, "89abcdefg", 9);
  __builtin_memcpy (a + 16, "h", 2);
  return __builtin_strlen (a);
}
which isn't optimized either and would also need the notion of length > N.
Surprisingly
int baz3 ()
{
  char a[30];
  __builtin_memcpy (a, "1234567", 8);
  __builtin_memcpy (a + 7, "89abcdefg", 10);
  __builtin_memcpy (a + 16, "h", 2);
  return __builtin_strlen (a);
}
isn't optimized either.