This allows to use any compatible types with INTERLOCKED_* macros, not just
the ones strictly matching the particular implementation of the intrinsics.
In particular, this fixes compilation for Cygwin64, which is an LP64 target,
meaning that long is 64-bit and _Interlocked* intrinsics use a different
integer type for its 32-bit integer arguments.
Additionally, enable use of intrin.h on Cygwin (32-bit).
The test has been updated to explicitly use 32-bit integer arguments.
There is a macro conflict for _InterlockedExchangePointer between intrin.h from
MSVC-12 and winnt.h from Windows SDK 8.1, which causes compilation failures.
This commit incorporates some of the changes made to
boost/smart_ptr/detail/sp_interlocked.hpp by Peter Dimov, namely:
- Define an internal config macro BOOST_INTERLOCKED_HAS_INTRIN_H when
the compiler is known to have a useful intrin.h header.
- Use this macro to select the common implementation based on intrin.h.
- Removed MinGW-w64 branch of implementation as it is now covered by
the common branch based on intrin.h.
- Added detection of clang-cl, a new MSVC pretender. The compiler is
assumed to have support for intrin.h.
- Added a separate branch for Windows CE >=6, with differently named
interlocked functions. No way to test this and no idea if this is
correct.
- For MSVC 8 and 9 don't use intrin.h as it reportedly conflicts
with <utility>. On these compilers we will declare the intrinsics
ourselves.
Reportedly, that code branch was not working an caused linking errors. As
reported in https://svn.boost.org/trac10/ticket/5431, Windows CE SDK still
provides Interlocked function definitions, but with slightly different
signatures. This PR keeps a single code branch for Windows CE that matches
the declarations described in the ticket. Untested.
This change is based on https://github.com/boostorg/winapi/pull/58
by James E. King, III <jking@apache.org>.
Fixes https://svn.boost.org/trac10/ticket/5431.
