From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32542 invoked by alias); 11 Sep 2016 09:56:04 -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 32519 invoked by uid 89); 11 Sep 2016 09:56:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-qk0-f179.google.com Received: from mail-qk0-f179.google.com (HELO mail-qk0-f179.google.com) (209.85.220.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 11 Sep 2016 09:55:52 +0000 Received: by mail-qk0-f179.google.com with SMTP id w204so118086777qka.0 for ; Sun, 11 Sep 2016 02:55:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CEQF5XNDbET6D+N5sgQusZkvGgsxGH4O1vQ9agivRf0=; b=kZFOVPZUF+RH3AQwtI1k1LNvu6YAYCmlFpOy/tWj0U3DDKCSdZpgVn8RYHXk+bWOOH Tbb68lsq7c9sZBGjJTZrpNuvqjNIKIpVZg/t4X9MGHG5DWzW8OVSz7qnWUgSA3dDS0b1 xcADzwSlC7HEjMrgeZHtzW34i6oFlzKI3CxPvSN5Kdiy8DvbwAOldIoYFdDm+2kUX0WV f6AbGsuq2N8RuP9GbY6HSlxxokWS7K24EK4Ar9PFQn84u/t9sr178kM/54PfJHfKSyuU /OII+ERERx6WI1Jyuot0yK23bcYYzA7oo8Py7mfKM2AibgMeZa5Mx/FVeeW67nyB4xhH X1fA== X-Gm-Message-State: AE9vXwPGsP+iVD6uySsXbSDIavtzuslChSUi654JA5n+5X8ulgqCa2cQ8jMAonZKSAZdwuxfcSd2TnZ8EZgB7Uzi X-Received: by 10.55.20.31 with SMTP id e31mr14005489qkh.256.1473587750867; Sun, 11 Sep 2016 02:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.21.102 with HTTP; Sun, 11 Sep 2016 02:55:49 -0700 (PDT) In-Reply-To: <20160911093847.GA29332@redhat.com> References: <20160908110641.GB23306@redhat.com> <20160911093847.GA29332@redhat.com> From: Christophe Lyon Date: Sun, 11 Sep 2016 10:20:00 -0000 Message-ID: Subject: Re: RFA (libstdc++): PATCH to implement C++17 over-aligned new To: Jonathan Wakely Cc: Jason Merrill , "libstdc++@gcc.gnu.org" , gcc-patches List Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00601.txt.bz2 On 11 September 2016 at 11:38, Jonathan Wakely wrote: > On 11/09/16 09:08 +0200, Christophe Lyon wrote: >> >> On 10 September 2016 at 08:59, Christophe Lyon >> wrote: >>> >>> On 9 September 2016 at 23:20, Jason Merrill wrote: >>>> >>>> On Thu, Sep 8, 2016 at 7:06 AM, Jonathan Wakely >>>> wrote: >>>>> >>>>> On 08/09/16 09:10 +0200, Marc Glisse wrote: >>>>>> >>>>>> >>>>>> Do we want a generic fallback implementation (similar to >>>>>> gcc/config/i386/gmm_malloc.h)? A windows version with _aligned_malloc >>>>>> / >>>>>> _aligned_free would also be possible. >>>>> >>>>> >>>>> Making it work for MinGW would be nice. >>>> >>>> >>>> OK, this is what I'm checking in; could someone test it on MinGW? >>>> >>>> Jason >>> >>> >>> Hi Jason, >>> >>> I'm seeing problems on arm*linux: the tests aligned-new[1235].C fail to >>> link: >>> aligned-new5.C:(.text+0x14): undefined reference to `operator >>> new(unsigned int, std::align_val_t)' >>> >>> >>> On aarch64*-elf and arm-eabi (using newlib), I'm seeing: >>> /gccsrc/libstdc++-v3/libsupc++/new_opa.cc:66: undefined reference to >>> `aligned_alloc' >>> >>> Am I missing something in my setup? >>> >> >> I'm seeing an additional problem: to GCC build is broken after this >> commit for target arm-none-eabi (using default cpu): >> >> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc: >> In function 'void* operator new(std::size_t, std::align_val_t, const >> std::nothrow_t&)': >> >> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:33:3: >> error: '__try' was not declared in this scope >> __try >> ^~~~~ >> >> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:11: >> error: expected primary-expression before '...' token >> __catch(...) >> ^~~ >> >> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:37:3: >> error: '__catch' was not declared in this scope >> __catch(...) >> ^~~~~~~ >> >> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:41:1: >> warning: no return statement in function returning non-void >> [-Wreturn-type] >> } >> ^ >> >> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:26: >> warning: unused parameter 'sz' [-Wunused-parameter] >> operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&) >> ^~ >> >> /home/christophe.lyon/src/GCC/sources/gcc-fsf/reg-240062/libstdc++-v3/libsupc++/new_opant.cc:30:47: >> warning: unused parameter 'al' [-Wunused-parameter] >> operator new(std::size_t sz, std::align_val_t al, const std::nothrow_t&) >> ^~ >> make[4]: *** [new_opant.lo] Error 1 >> make[4]: Leaving directory >> >> `/home/christophe.lyon/src/GCC/builds/gcc-fsf-reg-240062/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/libsupc++' > > > Hmm, I'm not sure why it's not failing on all targets, but this should I don't know either: the same target (arm-none-eabi) but --with-cpu=cortex-a9 does build. > fix it. Could you test it? > It's not sufficient: I had to apply the same change to new_opvant.cc for the build to complete. Thanks, Christophe