[PATCH] D112081: Define __STDC_NO_THREADS__ when targeting windows-msvc (PR48704)

Wed Oct 20 05:06:12 PDT 2021

aaron.ballman accepted this revision.
aaron.ballman added a comment.

In D112081#3073291 <https://reviews.llvm.org/D112081#3073291>, @rjmccall wrote:

> The standard answer is that compilers are designed to work with a specific set of system headers.  In the Clang-on-Windows case, that's complicated by the fact that many people acquire Clang separately from the rest of the build environment (although Microsoft does distribute Clang officially now, right?), but I think the standard answer is still ultimately the correct one: Clang is designed to support the MSVC system headers that are currently out in the world, and whenever Microsoft releases new system headers, it's possible that you will need a new version of Clang.
>
> As an aside, it's unfortunate that the name of this define makes it sound like not defining it implies that the environment is not concurrent.   Oh well; if the standard says it's tied to the header, then obviously it's right to not define it.

Yeah... I wish it was this clean and clear cut. :-D

N2731 (the latest C2x working draft) says in 6.10.8.3p1:

  __STDC_NO_THREADS__ The integer constant 1, intended to indicate that the implementation does not support the <threads.h> header.

Which seems pretty straight-forward, until you get to 7.26.1p2:

  Implementations that define the macro __STDC_NO_THREADS__ need not provide this header nor support any of its facilities.

and those facilities includes `thread_local` (the macro that expands to `_Thread_local`, the keyword), which got me wondering whether `_Thread_local` has any relationship with `__STDC_NO_THREADS__`. The standard did not claim there was, which supports the changes in this patch, but I remember this discussion happening in WG14. I dug around and found http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2291.htm that deals with exactly this question, and there was no consensus to adopt this proposal in WG14, so I eventually convinced myself this implementation is valid.

LGTM. :-)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D112081/new/

https://reviews.llvm.org/D112081