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, pins...@gmail.com wrote:
On Jan 16, 2015, at 9:57 PM, David Edelsohn <dje....@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
