https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #12 from Nicholas Miell <nmiell at gmail dot com> --- (In reply to Andrew Pinski from comment #9) > (In reply to Nicholas Miell from comment #8) > > 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. > > > aligned_alloc is part of C11 and C++17 and is required to be free'd by > std::free (or free in the C11 case). > > So this seems like a bug in tcmalloc not supplying an override of the C11 > function aligned_alloc. > > You would run into the same issue with a C11 application that does the same > too. That's not relevant, the language of the C++ standard doesn't require the application to also displace aligned_free when displacing the aligned versions of operator new or delete. The language of the standard also doesn't require the application to displace versions of operator new and delete that didn't yet exist in the version of the standard that the application targets. This version of tcmalloc predates aligned_alloc just as much as it predates the align_val_t variants of operator new and delete, and the whole point of an ABI is that existing binaries continue to work. libstdc++ has elected to provide one implementation of the C++ runtime that is ostensibly compatible with multiple revisions of the C++ language standard, the C++23 version of libstdc++.so.6 is required to continue to support all existing C++ executables dating back to at least 2004 (I'm not sure when version 6 was introduced). It is also required to simultaneously support multiple versions of the same C++ standard in a single process image, because that's how you chose to implement it.
