https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|WAITING |RESOLVED
--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Nicholas Miell from comment #12)
> That's not relevant, the language of the C++ standard doesn't require the
> application to also displace aligned_free when displacing the aligned
> versions of operator new or delete. The language of the standard also
> doesn't require the application to displace versions of operator new and
> delete that didn't yet exist in the version of the standard that the
> application targets.
There is no aligned_free; only free, that is part of the issue here; the C and
c++17 standard requires that memory that was allocated with aligned_alloc be
free'able with free.
If you displace free, and don't displace aligned_alloc then things will go
wrong. that is not an backwards compatiable ABI issue since you are overriding
free here and such.
> This version of tcmalloc predates aligned_alloc just as much as it predates
> the align_val_t variants of operator new and delete, and the whole
> point of an ABI is that existing binaries continue to work.
The ABI is backwards compatiable but in this case, it is not forwards
compatiable.
That is an issue.
Also aligned_alloc is from C11 (and C++17), just not many people used it until
recently (in this case via operator new).
Basically glibc ABI might be backwards compatiable but replacing things means
the ABI of tcmalloc needs to match the ABI that is being used for glibc.
Again you mention it is aligned_alloc and free that is being called in the end.
That is exactly not a libstdc++ issue at all, rather it is a glibc ABI issue.
