https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> --- We could also take the opportunity to look into whether any of those optimizations still buy us much performance. Is the compiler smart enough to turn the default implementation (in terms of a loop) into memcpy when needed? Presumably it can remove the entire loop from ranges::uninitialized_default_construct when it's invoking a trivial default constructor, so maybe we should just do the loop unconditionally? And presumably the compiler can turn uninitialized_value_construct into a memset when that's appropriate for the type (which the compiler knows better than the library code knows; in the library we only transform the loop to memset for 1-byte scalar types). The optimizations are useful for -O0 where the loop won't get optimized away, but do we care? If the optimizations are incorrect for constant evaluation and have subtleties with what they're allowed to do (e.g. we must use ranges::iter_move not std::move) then it would be simpler to just remove them all.
