gcc 4.7 does not support constexpr constructors that initialize one member
of an anonymous union data member of the class. atomic and atomic_flag
no longer have constexpr constructors on this compiler.
On 32-bit x86, 64-bit integers have 4-byte alignment, which resulted in
a non-integral type being selected for storage type in case of lock-based
atomic_ref. This broke arithmetic and bitwise operations on atomic_ref.
We now select an integral type based on its native alignment, not the storage
alignment we require for atomic operations. This is fine in case of lock-based
backend.
Also, extended buffer_storage with support for specifying alignment and removed
aligned_buffer_storage and storage128_t.
Lock-based operations have no reason to require object alignment higher
than alignof(T). This commit implements a special storage type for
lock-based operations, which has the same alignment as value_type.
Also, added tests to verify required_alignment correctness both
in lock-free and lock-based cases.
For some unknown reason, int128 bit operation tests started failing
in Travis CI for x86-64. The error does not reproduce locally. Given that
float128 were known to fail similarly (only on 32-bit target), it seems all
128-bit operations are broken in clang-5 (possibly caused by something
specific to Travis CI).
This commit re-enables 32-bit tests on clang-5, but disables int128 and
float128 tests on both 32 and 64-bit targets.
This works around MinGW compilation issues[1] and removes the otherwise
unnecessary dependency. Aligned storage is allocated manually on the stack.
[1]: https://github.com/boostorg/align/issues/10
The implementation used to generate 32-bit bts/btr/btc for 8 and 16-bit
atomics, which could result in alignment and access violation and possibly
data corruption. 32 and 64-bit atomics are unaffected.
This commit fixes operaend width for 16-bit atomics. For 8-bit atomics the
generic implementation is used based on or/and/xor instructions since there
are no 8-bit bts/btr/btc.
This is an attempt to make boost::atomic<> interface closer to the standard. It
makes a difference in C++17 as it mandates copy elision, which makes this code
possible:
boost::atomic<int> a = 10;
It also makes is_convertible<T, boost::atomic<T>> return true, which has
implications on the standard library components, such as std::pair.
This removes the workaround for gcc 4.7, which complains that
operator=(value_arg_type) is considered ambiguous with operator=(atomic const&)
in assignment expressions, even though conversion to atomic<> is less preferred
than conversion to value_arg_type. We try to work around the problem from the
operator= side.
Added a new compile test to check that the initializing constructor is implicit.
The support includes:
- The standard fetch_add/fetch_sub operations.
- Extra operations: (fetch_/opaque_)negate, (opaque_)add/sub.
- Extra capability macros: BOOST_ATOMIC_FLOAT/DOUBLE/LONG_DOUBLE_LOCK_FREE.
The atomic operations are currently implemented on top of the integer-based
backends and thus are mostly CAS-based. The CAS operations perform binary
comparisons, and as such have different behavior wrt. special FP values like
NaN and signed zero than normal C++.
The support for floating point types is optional and can be disabled by
defining BOOST_ATOMIC_NO_FLOATING_POINT. This can be useful if on a certain
platform parameters of the floating point types cannot be deduced from the
compiler-defined or system macros (in which case the compilation fails).
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0020r6.html
These operations are useful for two reasons. First, they are needed by
atomic<> interface as the pre-increment/decrement and add/subtract operators
need to perform the corresponding arithmetics and return the actual result while
not exhibiting UB in case of overflow. This means that the operation must be
performed on the unsigned storage type in the backend. Second, the (op)_and_test
operations on ARM and PowerPC can be implemented in a more generic way on top of
the operations that return the result. And since we have those operations
internally, why not expose them to users.
Added tests and docs for the new operations. Also, added docs for the recently
added scoped names of the memory_order enum values.
Also, added a specialized "emulated" backend for the extra operations. This
backend makes better use of the fact that the operations are lock-protected
by avoiding any CAS-based loops.
As the names suggest, the methods perform the corresponding operation and test
if the result is not zero.
Also, for the emulated fetch_complement, take care of integral promotion, which
could mess up the storage bits that were not part of the value on backends
where the storage is larger than the value. This could in turn break CAS on
the atomic value as it compares the whole storage.
This makes the result of (op)_and_test more consistent with other
methods such as test_and_set and bit_test_and_set, as well as the
methods used in the C++ standard library.
This is a breaking change. The users are able to define
BOOST_ATOMIC_HIGHLIGHT_OP_AND_TEST macro to generate warnings on each
use of the changed functions. This will help users to port from Boost
1.66 to newer Boost releases.
More info at:
https://github.com/boostorg/atomic/issues/11http://boost.2283326.n4.nabble.com/atomic-op-and-test-naming-
tc4701445.html
Fixed incorrect calculation of the min distance limit for arithmetic tests.
Moved some of the arithmetic tests to a separate function because
otherwise MSVC-10 for x64 generated broken code (the code would use
garbage values in registers to pass arguments to
add_and_test/sub_and_test).
Added output operators and employed newer test macros that output compared
values in case of test failure.
1. Expose value_type and difference_type (where present) to user's code.
2. Prohibit arithmetic operations on pointers to non-object types. In
particular, arithmetic operations such as fetch_add/fetch_sub will no longer
compile for pointers to cv void, pointers to functions and pointers to
non-static class members.
Also, use C++11 <type_traits> when possible instead of Boost.TypeTraits to
reduce dependencies. Cleaned up value_arg_type internal type usage for more
efficient argument passing.
Platform selection now works in two stages. First compiler is tested for
the supported configuration. If that fails, OS is tested. Lastly, if
nothing succeeded, emulation backend is selected.
