https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81330
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Wed, 5 Jul 2017, msebor at gcc dot gnu.org wrote: > GCC eliminates redundant calls to strlen() with intervening calls to strcpy > but > it misses an opportunity to do the same when the intervening call is to memcpy > instead. In the test case below, since both strcpy and memcpy require that > the > copies do not overlap, it's safe to assume that neither call modifies any part > of the source string, including the terminating nul, and so the second strlen > call can be replaced with the result of the first in both functions, not just > in f(). The strlen dump shows that GCC doesn't take advantage of this > guarantee in the memcpy case. > > (The second strlen call in g is replaced with the result of the first in g > when > memcpy is passed n0 + 1 as the size but I don't see why that should make a > difference.) I don't see the basis for the optimization with memcpy being safe without n0 + 1 as size. If the size is n0, it's perfectly legitimate for d to point to the terminating NUL, as in that case the memcpy arguments are adjacent but nonoverlapping blocks of n0 bytes in memory.
