https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Jonathan Wakely from comment #17) > (In reply to Nicholas Miell from comment #14) > > 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. To be clear, just like implementing it purely in terms of malloc, implementing aligned-new in terms of the C++98 new/delete would also require over-allocating and then aligning within the buffer, which wastes up to A-1 bytes in every allocation (where A is the requested alignment). If libc provides one of aligned_alloc, posix_memalign, memalign etc. then it's much better to use that. And if we do that, then providing multiple different libstdc++ runtimes for each version of the C++ standard would not help in the slightest, because there's still only one std::free, because that doesn't come from libstdc++ anyway. And multiple libstdc++ runtimes would cause problems when trying to combine a C++14 library into a C++17 application, because there would be more than one std::cout and other globals. Unlike the Windows model, the ELF linkage model doesn't support that well. It's not clear to me that it would solve any problems, certainly not the one being reported here, but it would cause new ones.
