On Wed, 14 Apr 2021 at 21:47, Jens Gustedt via Liaison
<liaison_at_[hidden]> wrote:
>
> Am 14. April 2021 20:07:18 MESZ schrieb JF Bastien <cxx_at_[hidden]>:
>>
>> On Wed, Apr 14, 2021 at 11:00 AM Uecker, Martin <Martin.Uecker_at_[hidden]> wrote:
>>>
>>> Am Mittwoch, den 14.04.2021, 08:54 -0700 schrieb JF Bastien via Liaison:
>>> > On Tue, Apr 13, 2021 at 11:40 AM Peter Sewell <Peter.Sewell_at_[hidden]>
>>> > wrote:
>>>
>>>
>>> > > - reading uninitialised representation bytes and padding bytes is also
>>> > > necessary for other bytewise polymorphic operations: memcmp, marshalling,
>>> > > encryption, and hashing (deferring what one knows about the results of
>>> > > such reads for a moment). It's not clear how generally these operations
>>> > > have to be supported, and we would like more data. Atomic cmpxchg on large
>>> > > structs, implemented with locks, would do a memcmp/memcpy combination (in
>>> > > fact is described as such in the standard).
>>> > >
>>> >
>>> > For atomics with padding, C++20 adopted the following change (and I expect
>>> > that compilers will implement it in previous versions as well):
>>> > http://wg21.link/P0528
>>>
>>> I am not terribly excited about this solution.
>>>
>>> I think C should stick to the memcmp/memcpy semantics of cmpxchg
>>> which operate on the representation including padding. This fits
>>> to the hardware instructions, simplifies compiler design (no
>>> need to look into each type), is easy to explain, handles all
>>> cases consistently including unions, and is what most
>>> C programmers would expect.
>>
>>
>> OK, but it doesn't work, as explained in the paper.
>
>
> Well, there is actually not much of an explanation in the paper.
>
> And doesn't work isn't much of a description

You need to look at the R0 revision
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0528r0.html