https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121026
Giuseppe D'Angelo <peppe at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |peppe at gcc dot gnu.org
--- Comment #4 from Giuseppe D'Angelo <peppe at gcc dot gnu.org> ---
Hi,
I think you analysis is spot-on.
There's this split at some conceptual level where in library code one thinks
"type has trivial X" == "I can avoid calling it" (trivial default constructor,
trivial destructor), or "it can be emulated via memcpy" (trivial copy/move
constructor), but that's not really true as far the language is concerned, is
it? And now (during constant evaluation) the compiler actually complains about
lifetime management.
> Maybe we want to just remove that partial specialization, or maybe we want to
> keep it but give it a destructor (for C++26 only?) that only destroys objects
> if ! consteval.
What is the concern at always leaving it in? The compiler is going to actually
generate calls to the destructor, and rely on the optimizer to get rid of them?
Are sanitizers possibly going to complain if we miss such calls?
> 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?
The optimizer doesn't always detect these cases and turns them into memcpy or
memset... having these optimizations at -O0 / -Og is nice in general.
Do you think it would be worth exploring new compiler builtins that e.g. do a
memcpy but also start lifetimes?
