https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81330
--- Comment #3 from Eric Gallager <egallager at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #2)
> You're right, I didn't consider this case. When copying (strlen(s) + 1) or
> more bytes, d cannot point at the terminating NUL at (s + strlen(s)) because
> the copy would then overlap, so the transformation is only valid for such
> copies. When copying fewer bytes than that (or when the number is unknown),
> it would not be valid. Thanks for clarifying that!
>
> So the missed optimization opportunity is in the "or more bytes" case, when
> GCC can also assume the NUL isn't overwritten. I.e., a test case for it
> would be the same as the original in comment #0 except with a call to
> __builtin_memcpy (d, s, n0 + 2) in g() (or any constant or known N greater
> than 1).
>
> Btw., the comment above handle_builtin_memcpy() in tree-ssa-strlen.c copied
> below hints that the constraint is deliberate but it doesn't explain why.
> I'll see about adding some detail to it since I happen to be working in this
> area.
You still working in this area nowadays?
>
> /* Handle a memcpy-like ({mem{,p}cpy,__mem{,p}cpy_chk}) call.
> If strlen of the second argument is known and length of the third argument
> is that plus one, strlen of the first argument is the same after this
> call. */
