This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>, libstdc++ at gcc dot gnu dot org, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 8 Sep 2016 11:50:51 +0100
- Subject: Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new
- Authentication-results: sourceware.org; auth=none
- References: <CADzB+2kJRV14hZX1rGz5V_UCpSB7MdVQPh4OM=vYOsw6ZDUNkA@mail.gmail.com>
On 08/09/16 02:06 -0400, Jason Merrill wrote:
This patch adds support for C++17 allocation of types with alignment
greater than max_align_t using 'new'. This is on by default in C++17
and can also be enabled for other -std= with -falign-new.
Nice.
If a user wants to use a different boundary than alignof(max_align_t),
perhaps because their malloc provides more or less alignment than
glibc's, they can specify -falign-new=<N>.
The patch also adds a warning about allocating an over-aligned type
without using an aligned new-operator, which is enabled by -Wall.
libstdc++ folk: Does my configury handling of different C library
functions that might be usable for aligned allocation make sense?
The AC_CHECK_FUNCS is OK but our configure munges all the autoconf
macros to add _GLIBCXX_ as a prefix, so you need to check
_GLIBCXX_HAVE_ALIGNED_ALLOC not HAVE_ALIGNED_ALLOC, and similarly for
the other two macros. Otherwise you always get this case:
+// The C library doesn't provide any aligned allocation functions, declare
+// aligned_alloc and get a link failure if aligned new is used.
+extern "C" void *aligned_alloc(std::size_t, std::size_t);
So it will fail for a pre-C11 libc even if it provides posix_memalign.
Is
the (standard-conforming) implementation of the nothrow allocation
function OK despite Jonathan's comment in bug 68210?
Yes. If anyone (maybe Taller Technologies?) cares about building
libstdc++ with -fno-exceptions then they can patch the new_op*.cc
files to do something different when !defined(__cpp_exceptions).
Or maybe I'll look at doing that as part of fixing 68210.
I'm still a little bothered about the try-catch overhead being
incurred for the std::nothrow_t allocation functions, but assuming
that allocation failure is rare that won't usually be a problem.
OK for trunk?
The libstdc++ parts are OK with the s/HAVE/_GLIBCXX_HAVE/ change.