On Tue, Feb 9, 2021 at 4:02 PM Hans Boehm <boehm_at_[hidden]> wrote:
>
> The papers that I mentioned that it would be really nice to discuss here are:
>
> wg21.link/p0943 - This has been adopted by wg21 in November.

Given that you're the paper author, I'm happy to schedule this for
SG22 review (sooner rather than later given that it's already been
adopted into the working draft).

> It assumes that we want _Atomic() and std::atomic<> to be synonymous in C++, which really only makes sense if _Atomic() has similar semantics in C. In particular, this gets questionable if C constrained _Atomic(T) to have the same alignment/size as T. That issue interacts with the type qualifier vs. specifier _Atomic issue in C. It would be nice to discuss this soon, since this probably has implications for both C++23 and C23. (A fallback here would be to remove _Atomic from the common subset and to limit that to atomic_int and friends. But that would be unfortunate.)
>
> wg21.link/p1478 - Byte-wise atomic memcpy. Much more esoteric, and less urgent.

I'm also happy to schedule this one.

I've tagged both papers for my own tracking, so we'll see them on our
plate at some point. Thank you for the suggestions!

~Aaron

> This is on track for adoption into a C++ TS. But given that it is C-like functionality, it would be good to understand WG14's opinion. Though esoteric, it seems to be functionality that we're otherwise lacking, and that many performance-sensitive systems eventually need. WG21 has repeatedly reinvented it in different forms.
>
> There are of course also various memory model efforts going on in a combination of WG14 and WG21 (out-of-thin-air, memory_order_consume replacement, pointer zap, provenance). Much of this is still exploratory at this stage, and is probably mostly OK the way it is? It will clearly have to affect both languages in the end, since these end up fundamentally affecting compiler back end assumptions.
>
> Hans