https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> --- Yes, but then we'd have *three* versions of std::equal: the default implementation using a for-loop, the optimized one using memcmp for PODs, and the constexpr form of the latter which also uses a for-loop. It would be more sensible to just use the default (not memcmp-optimized) one in constexpr contexts, but that requires using __builtin_constant_p in every function that is affected, instead of just replacing __builtin_memcmp with __constexpr_memcmp in the optimized version. Also, the more work that the algorithm does, the more concerned I'd be that although the inputs are constant (and so we use the naive for-loop) the actual work done in the loop might be too much to inline, so we make a run-time call to the slow version when we could use memcmp.
