<atomic>: Does atomic_thread_fence need compiler barriers when using _InterlockedIncrement?

I thought compiler barriers were implied for interlocked functions, but it doesn't look that way in atomic_thread_fence:
https://github.com/microsoft/STL/blob/62137922ab168f8e23ec1a95c946821e24bde230/stl/inc/atomic#L267

Instead of this:

_Compiler_barrier();
if (_Order == memory_order_seq_cst) {
    volatile long _Guard;
    (void) _InterlockedIncrement(&_Guard);
    _Compiler_barrier();
}

I would expect to see this:

if (_Order == memory_order_seq_cst) {
    volatile long _Guard;
    (void) _InterlockedIncrement(&_Guard);
} else {
    _Compiler_barrier();
}

If compiler barriers are actually needed for interlocked functions, I may have a lot of code to fix.

Start with stl/inc/atomic at the linked atomic_thread_fence implementation, then verify the compiler-barrier semantics of _InterlockedIncrement on the relevant MSVC targets. The issue is done when it is established whether the proposed barrier arrangement is correct and the implementation or related uses are updated if needed.