public inbox for libstdc++-cvs@sourceware.org help / color / mirror / Atom feed
From: Jonathan Wakely <redi@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org Subject: [gcc r14-7146] libstdc++: Prefer posix_memalign for aligned-new [PR113258] Date: Thu, 11 Jan 2024 17:55:54 +0000 (GMT) [thread overview] Message-ID: <20240111175554.A485D3858005@sourceware.org> (raw) https://gcc.gnu.org/g:f50f2efae9fb0965d8ccdb62cfdb698336d5a933 commit r14-7146-gf50f2efae9fb0965d8ccdb62cfdb698336d5a933 Author: Jonathan Wakely <jwakely@redhat.com> Date: Tue Jan 9 15:22:46 2024 +0000 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. Diff: --- libstdc++-v3/libsupc++/new_opa.cc | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/libstdc++-v3/libsupc++/new_opa.cc b/libstdc++-v3/libsupc++/new_opa.cc index 8326b7497fe..35606e1c1b3 100644 --- a/libstdc++-v3/libsupc++/new_opa.cc +++ b/libstdc++-v3/libsupc++/new_opa.cc @@ -46,12 +46,12 @@ using std::bad_alloc; using std::size_t; extern "C" { -# if _GLIBCXX_HAVE_ALIGNED_ALLOC +# if _GLIBCXX_HAVE_POSIX_MEMALIGN + void *posix_memalign(void **, size_t alignment, size_t size); +# elif _GLIBCXX_HAVE_ALIGNED_ALLOC void *aligned_alloc(size_t alignment, size_t size); # elif _GLIBCXX_HAVE__ALIGNED_MALLOC void *_aligned_malloc(size_t size, size_t alignment); -# elif _GLIBCXX_HAVE_POSIX_MEMALIGN - void *posix_memalign(void **, size_t alignment, size_t size); # elif _GLIBCXX_HAVE_MEMALIGN void *memalign(size_t alignment, size_t size); # else @@ -63,13 +63,10 @@ extern "C" #endif namespace __gnu_cxx { -#if _GLIBCXX_HAVE_ALIGNED_ALLOC -using ::aligned_alloc; -#elif _GLIBCXX_HAVE__ALIGNED_MALLOC -static inline void* -aligned_alloc (std::size_t al, std::size_t sz) -{ return _aligned_malloc(sz, al); } -#elif _GLIBCXX_HAVE_POSIX_MEMALIGN +// Prefer posix_memalign if available, because it's older than aligned_alloc +// and so more likely to be provided by replacement malloc libraries that +// predate the addition of aligned_alloc. See PR libstdc++/113258. +#if _GLIBCXX_HAVE_POSIX_MEMALIGN static inline void* aligned_alloc (std::size_t al, std::size_t sz) { @@ -83,6 +80,12 @@ aligned_alloc (std::size_t al, std::size_t sz) return ptr; return nullptr; } +#elif _GLIBCXX_HAVE_ALIGNED_ALLOC +using ::aligned_alloc; +#elif _GLIBCXX_HAVE__ALIGNED_MALLOC +static inline void* +aligned_alloc (std::size_t al, std::size_t sz) +{ return _aligned_malloc(sz, al); } #elif _GLIBCXX_HAVE_MEMALIGN static inline void* aligned_alloc (std::size_t al, std::size_t sz) @@ -128,7 +131,8 @@ operator new (std::size_t sz, std::align_val_t al) if (__builtin_expect (sz == 0, false)) sz = 1; -#if _GLIBCXX_HAVE_ALIGNED_ALLOC +#if _GLIBCXX_HAVE_POSIX_MEMALIGN +#elif _GLIBCXX_HAVE_ALIGNED_ALLOC # if defined _AIX || defined __APPLE__ /* AIX 7.2.0.0 aligned_alloc incorrectly has posix_memalign's requirement * that alignment is a multiple of sizeof(void*).
reply other threads:[~2024-01-11 17:55 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240111175554.A485D3858005@sourceware.org \ --to=redi@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ --cc=libstdc++-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).