diff options
author | Jonathan Wakely <jwakely@redhat.com> | 2024-01-09 15:22:46 +0000 |
---|---|---|
committer | Jonathan Wakely <jwakely@redhat.com> | 2024-01-11 17:35:57 +0000 |
commit | f50f2efae9fb0965d8ccdb62cfdb698336d5a933 (patch) | |
tree | 3dac68bdc47fc804bd0bfde20a633fc7995de3f0 /gcc | |
parent | 8f67953d0198fe9e053cc925eb631d2f29005466 (diff) | |
download | gcc-f50f2efae9fb0965d8ccdb62cfdb698336d5a933.zip gcc-f50f2efae9fb0965d8ccdb62cfdb698336d5a933.tar.gz gcc-f50f2efae9fb0965d8ccdb62cfdb698336d5a933.tar.bz2 |
libstdc++: Prefer posix_memalign for aligned-new [PR113258]
As described in PR libstdc++/113258 there are old versions of tcmalloc
which replace malloc and related APIs, but do not repalce aligned_alloc
because it didn't exist at the time they were released. This means that
when operator new(size_t, align_val_t) uses aligned_alloc to obtain
memory, it comes from libc's aligned_alloc not from tcmalloc. But when
operator delete(void*, size_t, align_val_t) uses free to deallocate the
memory, that goes to tcmalloc's replacement version of free, which
doesn't know how to free it.
If we give preference to the older posix_memalign instead of
aligned_alloc then we're more likely to use a function that will be
compatible with the replacement version of free. Because posix_memalign
has been around for longer, it's more likely that old third-party malloc
replacements will also replace posix_memalign alongside malloc and free.
libstdc++-v3/ChangeLog:
PR libstdc++/113258
* libsupc++/new_opa.cc: Prefer to use posix_memalign if
available.
Diffstat (limited to 'gcc')
0 files changed, 0 insertions, 0 deletions