https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Nicholas Miell <nmiell at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|RESOLVED |NEW
--- Comment #14 from Nicholas Miell <nmiell at gmail dot com> ---
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.
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.
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 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.
