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

[Sandra Loosemore <sandra at codesourcery dot com>]

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