hans added a comment. In D112081#3073067 <https://reviews.llvm.org/D112081#3073067>, @aaron.ballman wrote:
> Thanks for this! Should we similarly handle `__STDC_NO_ATOMICS__`, > `__STDC_NO_COMPLEX__`, et al at the same time? I'll look into those, thanks. > Also, how should we handle `__STDC_VERSION__`? We set that in all C modes, > but MSVC only sets it when passed /std:c11, etc explicitly. In any case we should probably do it separately. I don't really like MSVC's model where it's in a "traditional C with extensions" mode by default, but I clang-cl already also kind of does that because we don't define __STDC__ when targeting Windows. But it looks like unlike MSVC we also don't define it when passing /Za. And, I wonder how /Za and /std: are supposed to interact. In D112081#3073075 <https://reviews.llvm.org/D112081#3073075>, @aaron.ballman wrote: > Also, one concern I have for this is what to do if/when the Microsoft CRT > gets any of these features. Clang will be unconditionally setting > `__STDC_NO_WHATEVER__`, which we can correct for newer versions of Clang, but > still means older versions of Clang on those updated systems then report > something nonsensical. > > It'd be nice if Microsoft had a solution similar to stdc-predef.h used by > glibc, so the CRT could define information that we could use to determine > what macros to predefine rather than having to guess. I think the best we can do is make updates in future versions of Clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D112081/new/ https://reviews.llvm.org/D112081 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
