From patchwork Sat Jan 17 22:58:47 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jonathan Wakely X-Patchwork-Id: 430137 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 9A16D140161 for ; Sun, 18 Jan 2015 09:59:09 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; q=dns; s=default; b=wRWwI6pvv430Kn9Gm 5DRRzbKJmy0CXXeGE33nlntYFWiT4mMAnDPPgPMccVxPCV4Nlk0i+NEuTdp7OhgK kaLBmFa/m/LLf4wdMzlGVtie1iYF/IjoN8NBCWIFkZu8+4xGzXUvhEJ158Ceuh0b Y9OelyL1b5hY+ZterzYHgFWmpw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=default; bh=EFL2ugS3HhEkTGYEu34HLd5 M1EE=; b=wf8l670bLCi+SzdDPFq1XOIYmaYgDWQ0K+AJfdoDyIQsB5TLb+XM9Ey 0uBywy7oI+voovbD9VI64JS0jbFEaeVkPTV+q86GtdeoHsNE6OeHH98zTHuXHV0t Wp2PlzTX9i88zDi07i7dXdx1QcFeqKsd78lgqIiyWmtRBLZzx3ZQ= Received: (qmail 2156 invoked by alias); 17 Jan 2015 22:58:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 2123 invoked by uid 89); 17 Jan 2015 22:58:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, SPF_HELO_PASS, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 17 Jan 2015 22:58:52 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0HMwm2o018307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 17 Jan 2015 17:58:48 -0500 Received: from localhost (ovpn-116-25.ams2.redhat.com [10.36.116.25]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0HMwlZV020298; Sat, 17 Jan 2015 17:58:48 -0500 Date: Sat, 17 Jan 2015 22:58:47 +0000 From: Jonathan Wakely To: Sandra Loosemore Cc: Hans-Peter Nilsson , pinskia@gmail.com, David Edelsohn , Torvald Riegel , GCC Patches , "libstdc++@gcc.gnu.org" Subject: Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available. Message-ID: <20150117225847.GV3360@redhat.com> References: <9CAB68C4-08D2-43A1-9A8B-EDE135DDFC8F@gmail.com> <20150117134853.GR3360@redhat.com> <54BABF38.7080602@codesourcery.com> <20150117202356.GT3360@redhat.com> <54BAE0A4.8040303@codesourcery.com> <20150117223629.GU3360@redhat.com> <54BAE822.5050507@codesourcery.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <54BAE822.5050507@codesourcery.com> User-Agent: Mutt/1.5.23 (2014-03-12) On 17/01/15 15:54 -0700, Sandra Loosemore wrote: >On 01/17/2015 03:36 PM, Jonathan Wakely wrote: >>On 17/01/15 15:22 -0700, Sandra Loosemore wrote: >>[snip snip] >>>I'm getting a different series of build errors with this patch -- >>>starting with >>> >>>In file included from >>>/scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/futex.cc:27:0: >>> >>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:221:5: >>>error: 'mutex' does not name a type >>> mutex _M_mutex; >>> ^ >>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:222:5: >>>error: 'condition_variable' does not name a type >>> condition_variable _M_condvar; >>> ^ >>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h: >>>In member function 'unsigned int >>>std::__atomic_futex_unsigned<_Waiter_bit>::_M_load(std::memory_ >>>order)': >>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/bits/atomic_futex.h:230:7: >>>error: 'unique_lock' was not declared in this scope >>> unique_lock __lock(_M_mutex); >>> ^ >>>and going on for several screenfuls. >> >>Odd, that should already be fixed at rev 219799. >> >>Are you still at a revision older than that? > >My source tree is at r219802 now. My fault, this additional chunk is needed alongside the patch I sent earlier: What I sent earlier causes your target to use std::mutex and std::condition_variable, but without the bit above the headers aren't included. >>>Maybe the patch(es) causing all these problems should be reverted >>>until the breakage is tracked down and fixed and regression-tested on >>>a variety of targets? It's not really blocking me at the moment, but >>>it seems unfortunate that trunk is so unstable as we're entering Stage >>>4..... Torvald, if the extra change above doesn't fix it (although it should do) then maybe it should be reverted until it can be tested more widely. --- a/libstdc++-v3/include/bits/atomic_futex.h +++ b/libstdc++-v3/include/bits/atomic_futex.h @@ -35,7 +35,7 @@ #include #include #include -#if !defined(_GLIBCXX_HAVE_LINUX_FUTEX) +#if ! (defined(_GLIBCXX_HAVE_LINUX_FUTEX) && ATOMIC_INT_LOCK_FREE > 1) #include #include #endif