https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81330
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
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.
/* 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. */
