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 😃

C++ has a much complexer memory model. Much of what we are doing in this SG is meant to avoid going down the same rabbit hole.

One way that we could achieve this by axiomatically claiming that `memcpy` followed by `memcmp` does the right thing. Which seems to be wildly supported in the wild.

Jens

-- 
Jens Gustedt - INRIA & ICube, Strasbourg, France