From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Archive: List-Post: List-Help: Sender: gcc-patches-owner@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: Sun, 18 Jan 2015 00:24:00 -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-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <54BAE822.5050507@codesourcery.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-01/txt/msg01580.txt.bz2 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: --- 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 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.