From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94693 invoked by alias); 8 Sep 2016 10:50:56 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 94673 invoked by uid 89); 8 Sep 2016 10:50:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=posix_memalign, ac_check_funcs, *aligned_alloc, sk:_GLIBCX X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Sep 2016 10:50:54 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5548183F41; Thu, 8 Sep 2016 10:50:53 +0000 (UTC) Received: from localhost (ovpn-116-35.ams2.redhat.com [10.36.116.35]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u88AoqwQ004335; Thu, 8 Sep 2016 06:50:52 -0400 Date: Thu, 08 Sep 2016 11:00:00 -0000 From: Jonathan Wakely To: Jason Merrill Cc: gcc-patches List , libstdc++@gcc.gnu.org, "Joseph S. Myers" Subject: Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new Message-ID: <20160908105051.GA23306@redhat.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.7.0 (2016-08-17) X-SW-Source: 2016-09/txt/msg00429.txt.bz2 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=. > >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.