https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444
--- Comment #5 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- > Yes, so that std::copy_n benefits from the same memmove optimization as > std::copy. Right, I'm not objecting to the memmove optimization, just to the current codebase's approach of "slightly pessimize by going halfway down that alley, then find out memmove isn't possible and turn around and go back to the non-memmove path but now we've got a few extra instructions we can't go back and get rid of." The current approach is *not buggy*, but it would be *better* if copy_n could figure out the applicability of the memmove optimization on its own. I hadn't considered that there might [have] be[en] platforms on which a for-loop over integers might be faster than a while-loop over pointer comparisons. I'm pretty sure that's not true of any *mainstream* platform. But that could certainly have contributed to historical justification for the current approach.
