https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #21 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Nicholas Miell from comment #19) > (In reply to Jonathan Wakely from comment #17) > > > 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. > > > > Yeah, and I'm saying that you can't use aligned_alloc, specifically because > libstdc++.so.6 is supposed to be backwards compatible with binaries that > predate C11 and C++11 (or target versions of C/C++ before then), and because > the language spec allows programs to displace operator new and delete and > (in practice) programs that do that are also going to replace the C malloc > functions *but only the C malloc functions that existed at the time*. Again, this is not about replacing new/delete. That's allowed by the standard, and would work fine if you just replaced new/delete. The problem is that you've replaced malloc/free as well (or tcmalloc has replaced them for you). > In fact, instead of over-allocating and then aligning the returned pointer > in the enlarged region, you can probably get away with using posix_memalign > instead of aligned_alloc. That dates back to 2001, before the libstdc++.so.5 > to 6 SONAME bump and any allocator replacement you're going to encounter in > libstdc++.so.6 would've had to deal with the fact that free() has to be able > to free pointers returned from posix_memalign(). Does your library's old tcmalloc replace posix_memalign? > > 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. > > > > And if that were to happen it would have to be dealt with in some other way, > but in this particular oddball case where the C++ standard has an > underspecified poorly thought out feature, it unfortunately becomes the C++ > runtime's problem to deal with. How is this a problem of the C++ standard? The spec is clear: you can replace new/delete, and you can replace the aligned ones or the non-aligned ones or both. Your issue here is that libstdc++ uses aligned_alloc internally, which has nothing to do with the standard.
