Runtime: add a workaround for Windows ARM64

[compnerd]

Unfortunately, std::atomic in msvcprt as of 14.21.27702 is broken for
double-width atomics on ARM64. This has been reported to Microsoft and
is going to be fixed in VC++ 2019u3. For the time being, add a partial
template specialisation for the two double-word sized types temporarily
as a workaround. This allows the standard library build to get further.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

[compnerd]

CC: @jckarter @mikeash

[compnerd]

@swift-ci please smoke test

[mikeash]

This is mildly terrifying but looks like the right solution until VC++ fixes it.

[compnerd]

@mikeash - it seems that I have a tendency to come up with somewhat terrifying nuggets of code :-D

[mikeash]

It's an interesting talent to have.

Just curious, does the broken implementation fail spectacularly or is it just silently non-atomic or what?

[compnerd]

A bit of both really. So, the thing is that there is a compilation failure, but the true cause of the failure is obscured by the fact that SFINAE hides the fact that the there is a type mismatch on an intrinsic which causes _Unlock to fail to compile and thus get ignored - eventually, a reference to the _Unlock causes the compilation to fail as no definition could be synthesized.

This just works around it by providing the explicit template specialization which being a partial template specialization is given higher precedence and will suffice. The inline ensures that the definition is only emitted where used preventing the multiple definitions (as it is in a header).

[mikeash]

Interesting, thanks for explaining and for the fix.

[jfbastien]

The checks seem to capture non-MSVC compilers one ARM64 Windows. Does Swift care about e.g. clang-cl?

[compnerd]

@jfbastien yes, Swift cares about clang-cl as that is the compiler used to build Swift :-). This is working around msvcprt, not a cl issue.

[jckarter]

@jfbastien Only clang (and specifically Swift's branch of clang) can build the runtime.

[jfbastien]

OK, maybe I'm confused... This:

#if defined(_WIN32) && defined(_M_ARM64)

Looks like it'll trigger on cl as well as clang-cl, and that seems wrong since you only want it to trigger on cl?

[jckarter]

We're building with clang-cl, which still uses Microsoft's STL headers and C++ runtime, AIUI.

[jfbastien]

Ah OK, so this is working around an STL header issue, which is why #if defined(_WIN32) && defined(_M_ARM64) is required.