boost 1.56 compile fail with atomics failure

[niqingliang2003@…]

using gcc 4.9.1 with poky, cross compile boost 1.56 for s3c6410. -march=armv6

error info: libs/atomic/src/lockpool.cpp:127:5: error: 'thread_fence' is not a member of 'boost::atomics::detail' libs/atomic/src/lockpool.cpp:138:5: error: 'signal_fence' is not a member of 'boost::atomics::detail'

after dig into it, I found that: the marco 'BOOST_ATOMIC_FLAG_LOCK_FREE' is 0, so it don't include 'operations_lockfree.hpp' which has 'thread_fence' and 'signal_fence', but pthread.h at line 21.

in file 'caps_gcc_atomic.hpp', 'BOOST_ATOMIC_FLAG_LOCK_FREE' is set to '0', but at the end of 'caps_gcc_atomic.hpp', it defined 'BOOST_ATOMIC_THREAD_FENCE' as 2.

so the conflict is: BOOST_ATOMIC_THREAD_FENCE and BOOST_ATOMIC_FLAG_LOCK_FREE

I think 'BOOST_ATOMIC_THREAD_FENCE' should depend on 'BOOST_ATOMIC_FLAG_LOCK_FREE', do you think so?

[anonymous]

I have the same problem building for raspberry pi target.

[mrwombat]

Same problem here with raspberry pi, compiling with g++-4.8 (Raspbian 4.8.2-21~rpi3rpi1) 4.8.2, more info:

• 32-bit : yes
• arm : yes
• lockfree boost::atomic_flag : no
• has_icu builds : no

warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam

• zlib : yes
• iconv (libc) : yes
• icu : no
• icu (lib64) : no
• x86 : no
• gcc visibility : yes
• long double support : yes

Error: gcc.compile.c++ /tmp/build-boost/boost/bin.v2/libs/atomic/build/gcc-4.8/release/threading-multi/lockpool.o libs/atomic/src/lockpool.cpp: In static member function ‘static void boost::atomics::detail::lockpool::thread_fence()’: libs/atomic/src/lockpool.cpp:127:5: error: ‘thread_fence’ is not a member of ‘boost::atomics::detail’

atomics::detail::thread_fence(memory_order_seq_cst);

libs/atomic/src/lockpool.cpp: In static member function ‘static void boost::atomics::detail::lockpool::signal_fence()’: libs/atomic/src/lockpool.cpp:138:5: error: ‘signal_fence’ is not a member of ‘boost::atomics::detail’

atomics::detail::signal_fence(memory_order_seq_cst);

"g++-4.8" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -pthread -fPIC -std=c++11 -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_ATOMIC_SOURCE -DNDEBUG -I"." -c -o "/tmp/build-boost/boost/bin.v2/libs/atomic/build/gcc-4.8/release/threading-multi/lockpool.o" "libs/atomic/src/lockpool.cpp"

...failed gcc.compile.c++ /tmp/build-boost/boost/bin.v2/libs/atomic/build/gcc-4.8/release/threading-multi/lockpool.o... ...skipped <p/tmp/build-boost/boost/bin.v2/libs/atomic/build/gcc-4.8/release/threading-multi>libboost_atomic.so.1.56.0 for lack of <p/tmp/build-boost/boost/bin.v2/libs/atomic/build/gcc-4.8/release/threading-multi>lockpool.o... ...skipped <pstage/lib>libboost_atomic.so.1.56.0 for lack of <p/tmp/build-boost/boost/bin.v2/libs/atomic/build/gcc-4.8/release/threading-multi>libboost_atomic.so.1.56.0... ...skipped <pstage/lib>libboost_atomic.so for lack of <pstage/lib>libboost_atomic.so.1.56.0...

[Andrey Semashev]

@niqingliang2003:

I suspect that for some reason the compiler doesn't support atomic bools, but does support some other size atomics. Could you attach the output of the following command:

gcc -march=armv6  -dM -E - < /dev/null

Note the -march=armv6 argument - please specify it exactly as you do when compiling Boost (or don't specify it if you don't when building Boost).

I think 'BOOST_ATOMIC_THREAD_FENCE' should depend on 'BOOST_ATOMIC_FLAG_LOCK_FREE', do you think so?

No, it shouldn't. These macros are responsible for different features that are strictly speaking unrelated. More practically, I guess, every platform that supports atomic instructions can implement fences.

@mrwombat: You might need to explicitly add an -march=... argument. I'm not sure what target architecture is used by default.

[niqingliang2003@…]

result of $CXX -march=armv6 -dM -E - < /dev/null

[niqingliang2003@…]

I have uploaded the result of '$CXX -march=armv6 -dM -E - < /dev/null'. Please see the attachment.

[Andrey Semashev]

I've changed how the atomic backend treats cases when lesser-sized atomic ops are not supported while larger ones are.

​https://github.com/boostorg/atomic/commit/415db7054723291042e4ff1ffa8fdd5bc8b07163

Please, see if it helps in your case.