From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51611 invoked by alias); 23 Sep 2016 10:41:44 -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 51594 invoked by uid 89); 23 Sep 2016 10:41:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2756 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; Fri, 23 Sep 2016 10:41:33 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 6CD05C04D2AB; Fri, 23 Sep 2016 10:41:32 +0000 (UTC) Received: from localhost (ovpn-116-66.ams2.redhat.com [10.36.116.66]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8NAfVOJ013628; Fri, 23 Sep 2016 06:41:32 -0400 Date: Fri, 23 Sep 2016 10:48:00 -0000 From: Jonathan Wakely To: Christophe Lyon Cc: Ville Voutilainen , libstdc++ , "gcc-patches@gcc.gnu.org" Subject: Re: [v3 PATCH] PR libstdc++/77288 and the newest proposed resolution for LWG 2756 Message-ID: <20160923104131.GG17376@redhat.com> References: <20160921093115.GI17376@redhat.com> <20160922101602.GY17376@redhat.com> <20160922111506.GE17376@redhat.com> <20160922132502.GF17376@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/msg01668.txt.bz2 On 22/09/16 20:22 +0200, Christophe Lyon wrote: >On 22 September 2016 at 15:25, Jonathan Wakely wrote: >> On 22/09/16 12:15 +0100, Jonathan Wakely wrote: >>> >>> On 22/09/16 11:16 +0100, Jonathan Wakely wrote: >>>> >>>> (Somebody should fix PR58938 so exception_ptr is portable). >>> >>> >>> Christophe, would you be able to test this patch? >>> >>> It uses a single global mutex for exception_ptr objects, which doesn't >>> scale well but that probably isn't a problem for processors without >>> lock-free atomics for single words. >>> >>> This also solves the problem of mismatched -march options, where the >>> header is compiled for a CPU that supports the atomics but >>> libstdc++.so was built for an older CPU that doesn't support them, and >>> linking fails (as in https://gcc.gnu.org/PR58938#c13). >> >> >> We'd also need something like this extra piece, to ensure we don't >> leak exceptions. Currently __gxx_exception_cleanup assumes that if >> ATOMIC_INT_LOCK_FREE < 2 the referenceCount can never be greater than >> 1, because there are not exception_ptr objects that could increase it. >> >> If we enable exception_ptr unconditionally then that assumption >> doesn't hold. This patch uses the exception_ptr code to do the >> cleanup, under the same mutex as any other increments and decrements >> of the reference count. >> >> It's a bit of a hack though. >> >Should I have applied this one on top of the other? > >I ran a validation with it alone, and >arm-none-eabi with default mode, cpu, and fpu does not build: That's expected, the second patch requires the first one (you can't use exception_ptr unconditionally if it's only defined conditionally :-) >In file included from >/tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/eh_throw.cc:27:0: >/tmp/9260164_29.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/libsupc++/exception_ptr.h:43:4: >error: #error This platform does >not support exception propagation. > # error This platform does not support exception propagation. > ^~~~~ >make[4]: *** [eh_throw.lo] Error 1 > > >In addition, on arm-none-eabi --with-mode=thumb --with-cpu=cortex-a9, >I've noticed a regression in c++ > - PASS now FAIL [PASS => FAIL]: > > g++.dg/opt/pr36449.C -std=gnu++11 execution test > g++.dg/opt/pr36449.C -std=gnu++14 execution test > g++.dg/opt/pr36449.C -std=gnu++98 execution test > >My logs show: >qemu: uncaught target signal 11 (Segmentation fault) - core dumped Strange, I don't see how my patch could cause that. >The validation of the other patch is still running: I had to re-run it >because the >patch didn't apply because of the ChangeLog entry.