https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Nicholas Miell from comment #14) > Again, this version of tcmalloc predates aligned_alloc and the align_val_t > versions of operator new and delete. > > Again, the C++ standard does not require the application to displace > aligned_malloc when it displaces operator new or delete. > > Again, it is libstdc++ that is calling aligned_alloc, not the application. > > Again, the application displaced all the versions of operator new and delete > that were present in the version of the C++ standard that it targeted, in > addition to all the C malloc functions in the C standard it targeted. Replacing malloc and free is not allowed by the standard at all, so this is already outside the standard. > Again, libstdc++ broke the ABI when it introduced the align_val_t versions > of operator new and delete because existing correctly functioning > applications stopped working in the presence of the new version of libstdc++. > > Again, libstdc++ has elected to provide only one version of the C++ runtime > implementation that supports multiple versions of the C++ standard > simultaneously, instead of forking the library for every new revision of the > language standard. > > Again, you could probably fix this issue by implementing all of the newly > introduced versions of operator new and delete solely using the versions of > operator new and delete that were present when libstdc++.so.6 was first > introduced. We could do that, or we could just implement the aligned new in terms of malloc and over-allocate and manually align in the buffer (which is what we have to do for some targets without aligned_alloc or anything similar). But that sucks, and wastes memory and cycles. If aligned_alloc is supported, we use it. And that means we use free too. > Attempting to stick the blame on something other than libstdc++ doesn't even > solve the problem of the application crashing at startup, ultimately it will > have to be libstdc++ that works around this issue regardless. The > application certainly isn't getting updated, nor should it require updating; > that's the whole point of having ABIs in the first place. > > The C++23 standard says that whether the default versions of operator new > "involves a call to the C standard library functions malloc or aligned_alloc > is unspecified." I assert that a C++ runtime that purports to simultaneously > implement both C++14 and previous (which do not have aligned_alloc) and It's irrelevant whether C++14 has aligned_alloc, since libstdc++ doesn't provide that anyway. What matters is whether the underlying libc provides it. If it does, we call it. > C++17 and later (which do have aligned_alloc) must not call aligned_alloc in > the default behavior of any version of operator new as a basic quality of > implementation detail, given that C++14 and previous applications (which the > C++ runtime explicitly supports) are allowed to displace operator new and > delete without any knowledge of aligned_alloc. The problem has ABSOLUTELY NOTHING to do with replacing new/delete, it's ENTIRELY due to replacing malloc/free. You would get exactly the same problem in C code if your library using an old tcmalloc was called by a new application that used aligned_alloc and then called free, resulting in a call to the old tcmalloc free. This is not a libstdc++ problem, nor a C++ problem. If you want to blame the ABI break on something, blame C11 for adding aligned_alloc and requiring that free can handle it. Libstdc++ has no way to know if the version of free present at runtime can handle aligned_alloc. All we can tell is that aligned_alloc exists, we can't tell whether some library that might be linked to later breaks the libc ABI by replacing free in a way that makes aligned_alloc unusable.
