Message ID | 20150117202356.GT3360@redhat.com |
---|---|
State | New |
Headers | show |
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
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.....
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. > >> 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
diff --git a/libstdc++-v3/include/bits/atomic_futex.h b/libstdc++-v3/include/bits/atomic_futex.h index 2673604..b4138ba 100644 --- a/libstdc++-v3/include/bits/atomic_futex.h +++ b/libstdc++-v3/include/bits/atomic_futex.h @@ -49,7 +49,7 @@ namespace std _GLIBCXX_VISIBILITY(default) _GLIBCXX_BEGIN_NAMESPACE_VERSION #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1) -#if defined(_GLIBCXX_HAVE_LINUX_FUTEX) +#if defined(_GLIBCXX_HAVE_LINUX_FUTEX) && ATOMIC_INT_LOCK_FREE > 1 struct __atomic_futex_unsigned_base { // Returns false iff a timeout occurred. @@ -66,10 +66,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION { typedef chrono::system_clock __clock_t; - // XXX We expect this to be lock-free, and having the payload at offset 0. -#if ATOMIC_INT_LOCK_FREE < 2 -# error We require lock-free atomic operations on int -#endif + // This must be lock-free and at offset 0. atomic<unsigned> _M_data; __atomic_futex_unsigned(unsigned __data) : _M_data(__data) @@ -281,7 +278,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION }; -#endif // _GLIBCXX_HAVE_LINUX_FUTEX +#endif // _GLIBCXX_HAVE_LINUX_FUTEX && ATOMIC_INT_LOCK_FREE > 1 #endif // _GLIBCXX_HAS_GTHREADS && _GLIBCXX_USE_C99_STDINT_TR1 _GLIBCXX_END_NAMESPACE_VERSION