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.
