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.
