From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50483 invoked by alias); 10 Sep 2016 10:17:18 -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 50457 invoked by uid 89); 10 Sep 2016 10:17:17 -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= 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; Sat, 10 Sep 2016 10:17:07 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 04D7B61E5B; Sat, 10 Sep 2016 10:17:06 +0000 (UTC) Received: from localhost (ovpn-116-49.ams2.redhat.com [10.36.116.49]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8AAH4fM003360; Sat, 10 Sep 2016 06:17:05 -0400 Date: Sat, 10 Sep 2016 10:35:00 -0000 From: Jonathan Wakely To: libstdc++@gcc.gnu.org Cc: Christophe Lyon , Jason Merrill , gcc-patches List Subject: Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new Message-ID: <20160910101704.GG23306@redhat.com> References: <20160908110641.GB23306@redhat.com> 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/msg00579.txt.bz2 On 10/09/16 11:25 +0200, Marc Glisse wrote: >On Sat, 10 Sep 2016, Christophe Lyon wrote: > >>On aarch64*-elf and arm-eabi (using newlib), I'm seeing: >>/gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to >>`aligned_alloc' > >https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=f86afe5a3ac62a92e821c764a011e1625abdd326 > >"C11 aligned_alloc() implementation > >aligned_alloc() is implemented in terms of posix_memalign() which is >only declared in but not defined in Newlib in general. At >least Linux and RTEMS implement this function." > >If we don't want to provide a fallback implementation in libsupc++, we >can say that aligned new is unsupported on those platforms, but if we >are building a shared libstdc++.so that doesn't like undefined >symbols, we need a different failure mode than an undefined >aligned_alloc. Either not providing operator new(...aligned_val_t...) >in libstdc++ or providing one that just aborts I guess? Or always fails with bad_alloc: --- a/libstdc++-v3/libsupc++/new_opa.cc +++ b/libstdc++-v3/libsupc++/new_opa.cc @@ -49,8 +49,11 @@ aligned_alloc (std::size_t al, std::size_t sz) #define aligned_alloc memalign #else // 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); +// an aligned_alloc that always fails. +static void *aligned_alloc(std::size_t, std::size_t) +{ + _GLIBCXX_THROW_OR_ABORT(bad_alloc()); +} #endif #endif That would work unless/until we get a fallback.