================ @@ -89,6 +89,19 @@ sections with improvements to Clang's support for those languages. C++ Language Changes -------------------- +C++17 Feature Support +^^^^^^^^^^^^^^^^^^^^^ +- Clang now exposes ``__GCC_DESTRUCTIVE_SIZE`` and ``__GCC_CONSTRUCTIVE_SIZE`` + predefined macros to support standard library implementations of + ``std::hardware_destructive_interference_size`` and + ``std::hardware_constructive_interference_size``, respectively. These macros + are predefined in all C and C++ language modes. These macros can be + overridden on the command line with ``-D``, if desired. The values the macros ---------------- jyknight wrote:
> My comment was only to not encourage using -D. The fact it's defined through > a macro is really an implementation details, the macro is not meant to be > user facing. There should to be a user-facing way to set this, in order to pin it to a particular value. If not -D, then e.g. copy GCC's `--param hardware_destructive_interference_size=N` command-line. > we don't really make special cases for all the other potentially ABI-terrible > ideas people can come up with in a header file IMO, the special thing about this is that it's exposed by the standard library in a way that invites and suggests the _precise usage_ which is ABI-unstable. The purpose of `hardware_destructive_interference_size` is to put `alignas(std::hardware_destructive_interference_size)` on a struct. Yet, putting that into a header is a terrible idea almost all of the time -- it should be affected by -mtune, and may be changed by compiler upgrades. This is quite non-obvious issue for users, since the C++ stdlib generally goes to a huge amount of effort to remain ABI-stable for users. How do they know that _this_ constant is not ABI-stable, unlike the entire rest of the library? The way GCC handles it is to warn for _any_ use of `std::hardware_destructive_interference_size` in a header -- but only that one, not `hardware_constructive_interference_size`. I think the rationale is that the documented/expected usage of `destructive` is to use to add padding and/or alignment, while the documented/expected usage of `constructive` is to static_assert that a struct is smaller than it. It actually doesn't bother to warn on the internal __GCC_* macros at all. That may not be ideal, but it's a relatively simple solution that seems likely to be good enough. I think Clang could quite reasonably do the same thing. https://github.com/llvm/llvm-project/pull/89446 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
