https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #19 from Nicholas Miell <nmiell at gmail dot com> --- (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*. 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(). > 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. You're going to have to deal with this anyway if libstdc++ ever starts using the aligned new and delete operators internally, because libstdc++ has to stay compatible with programs that predate aligned_alloc. > 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. You can use dladdr() to figure out which shared libraries a symbol comes from and then make decisions about which features to used based on which subset of symbols come from which libraries. It probably could be done from an IFUNC resolver. Seems like overkill, though. Not using aligned_alloc at all would be easier.
