Fix runtime-atomics for Win 10 SDK and remove volatile

Fix runtime-atomics for Win 10 SDK and remove volatile

For unclear and probably accidental reasons the Windows 10 SDK
renamed some _Interlocked* functions to _InlineInterlocked. This
leads to these errors:

runtime-atomics.cc(159): error C3861: '_InterlockedExchange64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedExchangeAdd64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedAnd64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedOr64': identifier not found
runtime-atomics.cc(159): error C3861: '_InterlockedXor64': identifier not found

Fixing this requires either adding defines to map these five _Interlocked*
functions to _InlineInterlocked*, or else changing to using the
non-underscore versions. It appears that using the non-underscore versions
is preferable so I went that way. This also requires adding three  new
defines because there is a huge lack of consistency, probably due to these
macros being defined sometimes in <intrin.h> and sometimes in <winnt.h>

All five of the renamed 64-bit functions were manually checked to ensure
that the change to the non-underscore versions would make no differences -
the inline functions that they map to were identical. Other functions were
spot-checked.

Also, the 'volatile' qualifiers were removed. Volatile has no no useful
meaning for multi-threaded programming. It only exists in the Interlocked*
prototypes to *allow* volatile variables to be passed. Since this is a bad
habit to encourage there is no reason for us to permit it, and we can
still call the Microsoft functions (T* converts to volatile T*, just not
vice-versa).

The updated code builds with the Windows 8.1 SDK and with the Windows 10 SDK.

R=jarin@chromium.org
LOG=Y
BUG=440500, 491424
Committed: https://crrev.com/b2ed25304e203bbd22d6b09db575980f6aecf30a
Cr-Commit-Position: refs/heads/master@{#29687}

[Jarin, 2015-07-15 07:11:20]

lgtm.

While I agree that volatile has no useful meaning for multi-threading, it does
prevents some wilder compiler optimizations, and in the absence of any other
synchronization primitives it might be better than nothing. I think it is fine
to leave out 'volatile' here because the Interlocked* intrinsics should prevent
bad optimizations.

[brucedawson, 2015-07-15 16:45:17]

The CQ bit was checked by brucedawson@chromium.org

[commit-bot: I haz the power, 2015-07-15 16:45:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1228063005/1

[commit-bot: I haz the power, 2015-07-15 16:47:43]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-07-15 16:48:04]

Patchset 1 (id:??) landed as
https://crrev.com/b2ed25304e203bbd22d6b09db575980f6aecf30a
Cr-Commit-Position: refs/heads/master@{#29687}

[mauroleggieri, 2015-07-16 02:39:00]

Hi Bruce,

Thanks for the update. Yesterday I had the issue and today I saw a patch :)

Trying to compile V8 with v120_xp toolset (it uses SDK 7.1A), I have to add the
following code below 'runtime-utils.h' file include:

#if V8_CC_MSVC
#include <xatomic.h>
#if defined(_M_IX86)
  #define InterlockedAnd8                _InterlockedAnd8
  #define InterlockedOr8                 _InterlockedOr8
  #define InterlockedXor8                _InterlockedXor8

  #define InterlockedExchange16          _InterlockedExchange16
  #define InterlockedXor16               _InterlockedXor16

  #define InterlockedCompareExchange64   _InterlockedCompareExchange64
  #define InterlockedExchange64          _InterlockedExchange64_ASM
  #define InterlockedExchangeAdd64       _InterlockedExchangeAdd64_ASM
  #define InterlockedAnd64               _InterlockedAnd64_ASM
  #define InterlockedOr64                _InterlockedOr64_ASM
  #define InterlockedXor64               _InterlockedXor64_ASM
#elif defined(_M_X64))
  #define InterlockedExchange8           _InterlockedExchange8
  #define InterlockedExchange16          _InterlockedExchange16
#endif
#endif //V8_CC_MSVC

As you see, the code does not verify the platform toolset (to be honest, I don't
know how to get that info) so it may generate conflicts with VS2013's default
v120 toolset.

Kind regards,
Mauro.

[mauroleggieri, 2015-07-16 11:08:26]

Typo, extra closing parenthesis in '#elif defined(_M_X64))' line.

[brucedawson, 2015-07-17 00:52:10]

What is the use-case for building V8 with the v120_xp toolset? Is that something
that we need to support?

When I wrote my fix I was unaware of how to detect which Windows SDK was being
used. I have since learned how. You need to #include <ntverp.h> and then test
VER_PRODUCTBUILD, as shown here:

https://codereview.chromium.org/1233393002/diff/1/device/bluetooth/bluetooth_...

FWIW.

[mauroleggieri, 2015-10-01 23:22:20]

On 2015/07/17 00:52:10, brucedawson wrote:
> What is the use-case for building V8 with the v120_xp toolset? Is that
something
> that we need to support?
> 
> When I wrote my fix I was unaware of how to detect which Windows SDK was being
> used. I have since learned how. You need to #include <ntverp.h> and then test
> VER_PRODUCTBUILD, as shown here:
> 
>
https://codereview.chromium.org/1233393002/diff/1/device/bluetooth/bluetooth_...
> 
> FWIW.

Hi Bruce,

Sorry for the late response. Although many people is moving to newer OSes
(mainly Windows 10), XP is still used in some places and I think it is minor fix
that can be applied.

Regards,
Mauro.