https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #9 from Wilco <wilco at gcc dot gnu.org> --- (In reply to Martin Sebor from comment #7) > Rather than unconditionally transforming mempcpy to memcpy I would prefer to > see libc implementations of memccpy optimized. WG14 N2349 discusses a > rationale for this: > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2349.htm I don't think one precludes the other. memccpy is an odd interface, basically just a shorthand for memchr+memcpy. GLIBC already has an efficient generic implementation doing this - and like mempcpy it's unlikely many targets will add an optimized assembler version. So inlining in GCC would be best. Having so many non-standard string functions just means they are not optimized at all on most targets and never get significant use. I've spent a lot of time optimizing the generic string functions in GLIBC so they are at least not ridiculously slow (a loop doing 1 byte per iteration is unacceptable today).
