On Tuesday 15 October 2013 13:43:57 Gavin Lambert wrote:
On 15/10/2013 13:06, Quoth Andrey Semashev:
However, I would appreciate if you tried out the current trunk sans the commit 86144 to verify it works.
That could be awkward for me at present, but I'll see if I can try the 1.55 beta build, which should have the same effect as that commit hasn't been merged through yet.
Yes, 1.55 beta will do as well.
You're right, it looks like the windows.hpp changes have been misapplied, due to the changes between 1.54 and 1.55/trunk. (They're not *completely* useless, as it still defines a fallback path in case eg. BOOST_ATOMIC_INTERLOCKED_EXCHANGE_ADD64 is not defined on x64 for some reason, but as currently that can't happen it's a needless redundancy.)
There is no such configuration, on 64-bit targets all 64-bit intrinsics are available.
That macro is not defined when interlocked.hpp is included. The change to interlocked.hpp is not needed because windows.hpp doesn't use the _InterlockedCompareExchange64 intrinsic to implement cmpxchg8b.
I noticed that, although I'm not entirely sure why it doesn't. Wouldn't using the intrinsic be simpler than using the assembly code directly? It probably doesn't really matter in the end though, the effect should be the same.
The intrinsic is not supported by MSVC 7.1.