[libcxx-commits] [clang] [libcxx] [C++17] Support __GCC_[CON|DE]STRUCTIVE_SIZE (PR #89446)

[James Y Knight via libcxx-commits]

================
@@ -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