https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85721
--- Comment #3 from Mathias Stearn <redbeard0531 at gmail dot com> --- @Jonathan Wakely, that is because std::copy cheats and calls memmove directly. A slight modification of the type that shouldn't matter defeats that optimization and causes both forms to degrade to byte-by-byte: https://godbolt.org/g/Z4fWNT. I actually consider that the fact that the explicit optimization in std::copy is necessary should be considered an optimizer bug. Why isn't the optimizer noticing that the simple implementation is the same as a memmove and do the transformation for you? It generally seems unfortunate if similar code that clearly means the same thing results in very different performance. Ideally, even providing user-defined inline copy operations should result in calling memmove if they are equivalent since the compiler should be able to "see through" the non-triviality and optimize it all away. I'm filing these tickets based on what Martin Sebor said: "As an aside, using assignment and copy constructors should be at least as efficient as calling memset and memcpy, and ideally more, and they should always be preferred over the raw memory functions. If/where they aren't as efficient please open bugs for missing optimizations." Do you disagree with that statement?
