[boost] [atomic] gcc-atomic.hpp errors with Clang 3.4

Subject: [boost] [atomic] gcc-atomic.hpp errors with Clang 3.4
From: Richard Hadsell (hadsell_at_[hidden])
Date: 2014-03-12 14:34:38

I am trying to build Boost 1.55 libraries with Clang 3.4 using g++ 4.8.2 as the toolchain on CentOS 6.5.  I think these errors arise from trying to initialize 128-bit integers with 0:

clang-linux.compile.c++.without-pth bin.v2/libs/atomic/build/clang-linux-3.4/release/address-model-64/instruction-set-core2/link-static/threading-multi/lockpool.o
In file included from libs/atomic/src/lockpool.cpp:3:
In file included from ./boost/atomic.hpp:12:
In file included from ./boost/atomic/atomic.hpp:17:
In file included from ./boost/atomic/detail/platform.hpp:22:
./boost/atomic/detail/gcc-atomic.hpp:961:64: error: no matching constructor for initialization of 'storage_type' (aka 'boost::atomics::detail::storage128_type')
     explicit base_atomic(value_type const& v) BOOST_NOEXCEPT : v_(0)
                                                                ^  ~
./boost/atomic/detail/gcc-atomic.hpp:932:28: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::atomics::detail::storage128_type' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
                            ^
./boost/atomic/detail/gcc-atomic.hpp:932:28: note: candidate constructor (the implicit default constructor) not viable: requires 0 arguments, but 1 was provided
./boost/atomic/detail/gcc-atomic.hpp:968:22: error: no viable conversion from 'int' to 'storage_type' (aka 'boost::atomics::detail::storage128_type')
         storage_type tmp = 0;
                      ^     ~
./boost/atomic/detail/gcc-atomic.hpp:932:28: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::atomics::detail::storage128_type &' for 1st argument
struct BOOST_ALIGNMENT(16) storage128_type
                            ^

Similar errors follow these.

I think the initializations to 0 are superfluous, because they are followed by memcpy calls that overwrite them.  I will try that fix myself, but I am looking for an official fix that will get into the next release.

-- 
Dick Hadsell			203-992-6320  Fax: [phone]
Reply-to:			hadsell_at_[hidden]
Blue Sky Studioshttp://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560
Follow Blue Sky Studios on Facebook <http://www.facebook.com/BlueSkyStudios> and Twitter <http://twitter.com/#%21/blueskystudios>