From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21273 invoked by alias); 17 Jan 2015 22:36:37 -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 21254 invoked by uid 89); 17 Jan 2015 22:36:36 -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,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:36:35 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0HMaUM1018164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 17 Jan 2015 17:36:31 -0500 Received: from localhost (ovpn-116-25.ams2.redhat.com [10.36.116.25]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0HMaTn6012885; Sat, 17 Jan 2015 17:36:30 -0500 Date: Sat, 17 Jan 2015 22:58: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: <20150117223629.GU3360@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <54BAE0A4.8040303@codesourcery.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-01/txt/msg01577.txt.bz2 On 17/01/15 15:22 -0700, Sandra Loosemore wrote: >On 01/17/2015 01:23 PM, Jonathan Wakely wrote: >>On 17/01/15 12:59 -0700, Sandra Loosemore wrote: >>>Re: >>> >>>>On 17/01/15 01:45 -0500, Hans-Peter Nilsson wrote: >>>>>On Fri, 16 Jan 2015, pinskia@gmail.com wrote: >>>>>>>On Jan 16, 2015, at 9:57 PM, David Edelsohn >>>>>>>wrote: >>>>>>> >>>>>>>This patch has broken bootstrap on AIX >>>>>>> >>>>>>>May I mention that this really should have been tested on systems >>>>>>>other than x86 Linux. >>>>>> >>>>>>It also broke all newlib targets too. So you could have tested one >>>>>>listed in the sim-test web page. >>>>> >>>>>For those interested, PR64638. >>>> >>>>Should be fixed in trunk now, by this patch. >>> >>>I'm now getting this error in an arm-none-linux-gnueabi cross build: >>> >>> >>>In file included from >>>/scratch/sandra/arm-fsf2/obj/gcc-mainline-0-arm-none-linux-gnueabi-i686-pc-linux-gnu/arm-none-linux-gnueabi/libstdc++-v3/include/future:44:0, >>> >>> from >>>/scratch/sandra/arm-fsf2/src/gcc-mainline/libstdc++-v3/src/c++11/functexcept.cc:34: >>> >>>/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:71:3: >>>error: #error We require lock-free atomic operations on int >>># error We require lock-free atomic operations on int >>> ^ >>> >>>It used to work a few days ago.... nothing changed in my build >>>environment except that I did "svn up" in my gcc source directory.... >> >>Well that file didn't exist until yesterday :-) >> >>Does the attached patch fix it? >> >>The new __atomic_futex_unsigned type is only used in when >>ATOMIC_LOCK_FREE > 1, so there's no point trying to define it and >>then failing if int is not lock-free, as the type isn't going to be >>used anyway. > >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? >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.....