Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new

[Jonathan Wakely <jwakely@redhat.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.