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

Sandra Loosemore sandra@codesourcery.com
Sat Jan 17 22:54:00 GMT 2015


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.

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

-Sandra



More information about the Gcc-patches mailing list