hubert.reinterpretcast added inline comments.
================
Comment at: clang/lib/Basic/Targets/OSTargets.h:730
+ MacroBuilder &Builder) const override {
+ Builder.defineMacro("_LONG_LONG");
+ Builder.defineMacro("_OPEN_DEFAULT");
----------------
The comment from https://reviews.llvm.org/D85324?id=283290#inline-786609
applies here as well. `_LONG_LONG` should not be defined under `-std=c89
-pedantic-errors` or `-std=c89 -Werror=long-long`.
================
Comment at: clang/lib/Basic/Targets/OSTargets.h:753
+ Builder.defineMacro("__DLL__");
+ // Macro __wchar_t is defined so wchar_t data type
+ // is not declared as a typedef in system headers.
----------------
s/so wchar_t/so that the wchar_t/;
================
Comment at: clang/lib/Basic/Targets/OSTargets.h:755
+ // is not declared as a typedef in system headers.
+ Builder.defineMacro("__wchar_t");
+ // XOPEN_SOURCE=600 is required to build libcxx.
----------------
The corresponding AIX code checks for `-Xclang -fno-wchar`. The behaviour of
`stddef.h` differs when using `-fno-wchar` between AIX and Linux though. Linux
suppresses the typedef based on `__cplusplus`. Arguably, the OS header
difference should not really factor into whether the compiler defines a macro
that indicates the presence of a `wchar_t` fundamental type.
================
Comment at: clang/lib/Basic/Targets/OSTargets.h:766
+ if (Opts.C11 || Opts.GNUMode) {
+ Builder.defineMacro("__IBM_UTF_LITERAL");
+ Builder.defineMacro("__IBMC_NORETURN");
----------------
The GNU extension modes do not cause u-prefixed, etc. string literals to be
accepted where the base language level would treat the prefix as a separate
identifier. Also noting here that the previous comment from
https://reviews.llvm.org/D85324?id=283290#inline-786628 was made based on
noting that `__IBM_UTF_LITERAL` is defined by the XL compiler in the
appropriate C++ modes.
================
Comment at: clang/lib/Basic/Targets/OSTargets.h:767
+ Builder.defineMacro("__IBM_UTF_LITERAL");
+ Builder.defineMacro("__IBMC_NORETURN");
+ }
----------------
I would expect that the Clang implementation of the "IBM-style" feature test
macros would behave similarly to the native feature testing in Clang. That is,
`__IBMC_NORETURN` is defined when `_Noreturn` is available as an extension.
`_Noreturn` is available as an "orthogonal" or "conforming" extension in modes
such as `-std=c89` and `-std=c++03`. The extension is disabled via
warnings-as-errors.
================
Comment at: clang/lib/Basic/Targets/OSTargets.h:770
+
+ if (Opts.CPlusPlus11 || (Opts.GNUMode && Opts.CPlusPlus)) {
+ Builder.defineMacro("__IBM_CHAR16_T__");
----------------
See comment above re: GNU extension modes not enabling u-prefixed, etc.
literals.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D85324/new/
https://reviews.llvm.org/D85324
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
