[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete

[nmiell at gmail dot com]

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.