[patch libstdc++] Optimize synchronization in std::future if futexes are available.

[Jonathan Wakely]

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 <dje.gcc@gmail.com>
>>>>>>>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 <future> 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<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?

>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.....