This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: Hans-Peter Nilsson <hp at bitrange dot com>, pinskia at gmail dot com, David Edelsohn <dje dot gcc at gmail dot com>, Torvald Riegel <triegel at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Date: Sat, 17 Jan 2015 22:58:47 +0000
- Subject: Re: [patch libstdc++] Optimize synchronization in std::future if futexes are available.
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnyng32Rh7US3Azhao9B=JMnsZaJ_1vRik36wQ4FKWm1BkQ at mail dot gmail dot com> <9CAB68C4-08D2-43A1-9A8B-EDE135DDFC8F at gmail dot com> <alpine dot BSF dot 2 dot 02 dot 1501170144070 dot 76242 at arjuna dot pair dot com> <20150117134853 dot GR3360 at redhat dot com> <54BABF38 dot 7080602 at codesourcery dot com> <20150117202356 dot GT3360 at redhat dot com> <54BAE0A4 dot 8040303 at codesourcery dot com> <20150117223629 dot GU3360 at redhat dot com> <54BAE822 dot 5050507 at codesourcery dot com>
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<mutex> __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 <bits/c++config.h>
#include <atomic>
#include <chrono>
-#if !defined(_GLIBCXX_HAVE_LINUX_FUTEX)
+#if ! (defined(_GLIBCXX_HAVE_LINUX_FUTEX) && ATOMIC_INT_LOCK_FREE > 1)
#include <mutex>
#include <condition_variable>
#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.