[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF updated this revision to Diff 96043.
EricWF added a comment.

- Address inline comments.


https://reviews.llvm.org/D32265

Files:
  lib/Frontend/InitPreprocessor.cpp
  test/Preprocessor/init.c
  test/Sema/atomic-ops.c

Index: test/Sema/atomic-ops.c
===
--- test/Sema/atomic-ops.c
+++ test/Sema/atomic-ops.c
@@ -7,19 +7,29 @@
 struct S { char c[3]; };
 
 _Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == __CLANG_ATOMIC_BOOL_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == __CLANG_ATOMIC_CHAR_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == __CLANG_ATOMIC_CHAR16_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == __CLANG_ATOMIC_CHAR32_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == __CLANG_ATOMIC_WCHAR_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == __CLANG_ATOMIC_SHORT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == __CLANG_ATOMIC_INT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == __CLANG_ATOMIC_LONG_LOCK_FREE, "");
 #ifdef __i386__
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 1, "");
 #else
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 2, "");
 #endif
+_Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == __CLANG_ATOMIC_LLONG_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == __CLANG_ATOMIC_POINTER_LOCK_FREE, "");
 
 _Static_assert(__c11_atomic_is_lock_free(1), "");
 _Static_assert(__c11_atomic_is_lock_free(2), "");
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -8846,6 +8846,16 @@
 // WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY32-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9162,6 +9172,16 @@
 // WEBASSEMBLY64-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY64-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY64-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY64-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY64-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY64-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9637,3 +9657,36 @@
 // AVR:#define __WCHAR_MAX__ 32767
 // AVR:#define __WCHAR_TYPE__ int
 // AVR:#define __WINT_TYPE__ int
+
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple i686-windows-msvc -fms-compatibility < /dev/null \
+// RUN:  | FileCheck -match-full-lines -check-prefix MSVC-X32 %s
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple x86_64-windows-msvc -fms-compatibility < /dev/null \
+// RUN:  | FileCheck -match-full-lines -check-prefix MSVC-X64 %s
+
+// MSVC-X32:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// MSVC-X32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// MSVC-X32-NEXT:#define 

[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread Richard Smith via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

I'm not thrilled about adding yet more predefined macros, but it really doesn't 
make sense for libc++ to depend on `__GCC_*` macros when targeting Windows, nor 
for these to be Windows-only, so let's do it.




Comment at: lib/Frontend/InitPreprocessor.cpp:910-912
+  addLockFreeMacros("__CLANG_ATOMIC");
+  if (!LangOpts.MSVCCompat)
+addLockFreeMacros("__GCC_ATOMIC");

I'd sink the `_` into the prefix too, but this looks fine either way.


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread Billy Robert O'Neal III via Phabricator via cfe-commits
BillyONeal added a comment.

In https://reviews.llvm.org/D32265#731709, @jfb wrote:

> Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL 
> implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't seem to 
> have anything ? Presumably they'll have to do 
> *something*.


Our STL implements  entirely as a library feature (on top of the 
_InterlockedXxx intrinsics and alignas).


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread Billy Robert O'Neal III via Phabricator via cfe-commits
BillyONeal added a comment.

(sorry for double post)

And of course since you folks don't care about supporting pre-Vista you 
probably also don't care about supporting Opterons from 2005, in which case 
you'd want unconditional cmpxchg16b on amd64 :). In our next major version I 
added a configuration macro `_STD_ATOMIC_ALWAYS_USE_CMPXCHG16B` users can set 
to ask for that.


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

In https://reviews.llvm.org/D32265#732649, @jfb wrote:

> In https://reviews.llvm.org/D32265#731710, @EricWF wrote:
>
> > In https://reviews.llvm.org/D32265#731709, @jfb wrote:
> >
> > > Is it a goal to support Microsoft's STL with this? If so, how does MSVC's 
> > > STL implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't 
> > > seem to have anything ? Presumably they'll 
> > > have to do *something*.
> >
> >
> > The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on 
> > Windows using Clang. As you know libc++ currently uses the 
> > `__GCC_ATOMIC_FOO` macros, but those aren't available on Windows.
>
>
> OK so it's just a hygiene question of blanket-avoiding `__GCC_*` macros in 
> clang-ms mode, but using `__CLANG_*` macros are OK? That sounds fine then. 
> Would you all-out switch libc++ to use `__CLANG_*` then?


`__CLANG` macros are fine on libc++'s end; So as long as they're not uncouth 
for Clang it should be OK.

I would switch libc++ to do

  #ifdef __CLANG_ATOMIC_FOO
  # define ATOMIC_FOO __CLANG_ATOMIC_FOO
  # define ATOMIC_BAR __CLANG_ATOMIC_BAR
  #else
  # define ATOMIC_FOO __GCC_ATOMIC_FOO
  ...
  #endif



> 
> 
>> Also AFAIK MSVC leaves the implementation of atomics up to the library, not 
>> the frontend. So W/E MSVC's STL does it's likely not sane or desirable.
> 
> Wait what? How does that even work? This calls for a Twitter ping of Billy!




https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread Billy Robert O'Neal III via Phabricator via cfe-commits
BillyONeal added a comment.

In https://reviews.llvm.org/D32265#732657, @jfb wrote:

> It looks like Billy is going to do something somewhat similar when he 
> rewrites it: https://twitter.com/jfbastien/status/855168230918307840
>  For now it's kinda `#define IS_LOCK_FREE ¯\_(ツ)_/¯`


Note that my rewrite of our  didn't touch the XXX_IS_LOCK_FREE macros. 
All of those for both implementations are hardcoded to 2 since any piece of 
hardware we ever plan to support has lock free ops for all those. I did add 
conditional DCAS support for amd64 though in v.Next.

Billy3


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

It looks like Billy is going to do something somewhat similar when he rewrites 
it: https://twitter.com/jfbastien/status/855168230918307840
For now it's kinda `#define IS_LOCK_FREE ¯\_(ツ)_/¯`


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

In https://reviews.llvm.org/D32265#731710, @EricWF wrote:

> In https://reviews.llvm.org/D32265#731709, @jfb wrote:
>
> > Is it a goal to support Microsoft's STL with this? If so, how does MSVC's 
> > STL implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't 
> > seem to have anything ? Presumably they'll 
> > have to do *something*.
>
>
> The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on Windows 
> using Clang. As you know libc++ currently uses the `__GCC_ATOMIC_FOO` macros, 
> but those aren't available on Windows.


OK so it's just a hygiene question of blanket-avoiding `__GCC_*` macros in 
clang-ms mode, but using `__CLANG_*` macros are OK? That sounds fine then. 
Would you all-out switch libc++ to use `__CLANG_*` then?

> Also AFAIK MSVC leaves the implementation of atomics up to the library, not 
> the frontend. So W/E MSVC's STL does it's likely not sane or desirable.

Wait what? How does that even work? This calls for a Twitter ping of Billy!


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF added a comment.

In https://reviews.llvm.org/D32265#731709, @jfb wrote:

> Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL 
> implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't seem to 
> have anything ? Presumably they'll have to do 
> *something*.


The goal is to allow libc++ to implement`ATOMIC__LOCK_FREE` on Windows 
using Clang. As you know libc++ currently uses the `__GCC_ATOMIC_FOO` macros, 
but those aren't available on Windows.

Also AFAIK MSVC leaves the implementation of atomics up to the library, not the 
frontend. So W/E MSVC's STL does it's likely not sane or desirable.


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-20 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

Is it a goal to support Microsoft's STL with this? If so, how does MSVC's STL 
implement `is_always_lock_free` at the moment? CL 19 2017 RTW doesn't seem to 
have anything ? Presumably they'll have to do 
*something*.


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-19 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai resigned from this revision.
smeenai edited reviewers, added: compnerd; removed: smeenai.
smeenai added a comment.

This looks good to me, but I'm not familiar enough with this part of clang to 
be comfortable accepting.


https://reviews.llvm.org/D32265



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D32265: Add __CLANG_ATOMIC__LOCK_FREE macros for use in MSVC compatibility mode.

2017-04-19 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF created this revision.
Herald added subscribers: dschuff, jfb.

Libc++ currently implements the `ATOMIC__LOCK_FREE` macros using the 
`__GCC_ATOMIC__LOCK_FREE` macros. However these are not available when 
MSVC compatibility is enabled even though C11 `_Atomic` is.  This prevents 
libc++ from correctly implementing `ATOMIC__LOCK_FREE`.

This patch adds an alternative spelling `__CLANG_ATOMIC__LOCK_FREE` that 
is enabled with `-fms-compatibility`.


https://reviews.llvm.org/D32265

Files:
  lib/Frontend/InitPreprocessor.cpp
  test/Preprocessor/init.c
  test/Sema/atomic-ops.c

Index: test/Sema/atomic-ops.c
===
--- test/Sema/atomic-ops.c
+++ test/Sema/atomic-ops.c
@@ -7,19 +7,29 @@
 struct S { char c[3]; };
 
 _Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_BOOL_LOCK_FREE == __CLANG_ATOMIC_BOOL_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR_LOCK_FREE == __CLANG_ATOMIC_CHAR_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR16_T_LOCK_FREE == __CLANG_ATOMIC_CHAR16_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_CHAR32_T_LOCK_FREE == __CLANG_ATOMIC_CHAR32_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_WCHAR_T_LOCK_FREE == __CLANG_ATOMIC_WCHAR_T_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_SHORT_LOCK_FREE == __CLANG_ATOMIC_SHORT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_INT_LOCK_FREE == __CLANG_ATOMIC_INT_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_LONG_LOCK_FREE == __CLANG_ATOMIC_LONG_LOCK_FREE, "");
 #ifdef __i386__
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 1, "");
 #else
 _Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == 2, "");
 #endif
+_Static_assert(__GCC_ATOMIC_LLONG_LOCK_FREE == __CLANG_ATOMIC_LLONG_LOCK_FREE, "");
 _Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == 2, "");
+_Static_assert(__GCC_ATOMIC_POINTER_LOCK_FREE == __CLANG_ATOMIC_POINTER_LOCK_FREE, "");
 
 _Static_assert(__c11_atomic_is_lock_free(1), "");
 _Static_assert(__c11_atomic_is_lock_free(2), "");
Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -8846,6 +8846,16 @@
 // WEBASSEMBLY32-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY32-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY32-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 1
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY32-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY32-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY32-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY32-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9162,6 +9172,16 @@
 // WEBASSEMBLY64-NEXT:#define __CHAR32_TYPE__ unsigned int
 // WEBASSEMBLY64-NEXT:#define __CHAR_BIT__ 8
 // WEBASSEMBLY64-NOT:#define __CHAR_UNSIGNED__
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_BOOL_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR16_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR32_T_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_CHAR_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_INT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LLONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_LONG_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_POINTER_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_SHORT_LOCK_FREE 2
+// WEBASSEMBLY64-NEXT:#define __CLANG_ATOMIC_WCHAR_T_LOCK_FREE 2
 // WEBASSEMBLY64-NEXT:#define __CONSTANT_CFSTRINGS__ 1
 // WEBASSEMBLY64-NEXT:#define __DBL_DECIMAL_DIG__ 17
 // WEBASSEMBLY64-NEXT:#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
@@ -9637,3 +9657,36 @@
 // AVR:#define __WCHAR_MAX__ 32767
 // AVR:#define __WCHAR_TYPE__ int
 // AVR:#define __WINT_TYPE__ int
+
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple i686-windows-msvc -fms-compatibility < /dev/null \
+// RUN:  | FileCheck -match-full-lines -check-prefix MSVC-X32 %s
+
+// RUN: %clang_cc1 -E -dM -ffreestanding \
+// RUN:-triple x86_64-windows-msvc -fms-compatibility <