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