https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #8 from Nicholas Miell <nmiell at gmail dot com> --- (In reply to Jonathan Wakely from comment #7) > (In reply to Nicholas Miell from comment #0) > > This is typically the result of the libstdc++ version of operator > > delete(void* ptr, std::align_val_t alignment) calling the > > application-supplied version of operator delete(void* ptr), > > But it doesn't do that. > > The libstdc++ version of operator delete(void*, size_t, align_val_t) calls > std::free directly, because that's the correct way to free memory obtained > by the libstdc++ version of the operator new(size_t, align_val_t). > Oh, I'm sorry, I did the initial investigation a couple weeks ago and only wrote this up (from memory) when I started clearing out stale browser tabs today. I guess I falsely assumed I had a better understanding of the issue than I actually did, and I looked at the wrong operator delete when I was checking my flawed assumptions. What appears to actually be happening is that the libstdc++ operator new(std::size_t size, std::align_val_t alignment) is calling glibc's aligned_alloc, and then the libstdc++ operator delete(void* ptr, std::align_val_t alignment) is calling std::free(), which is supplied by tcmalloc.
