[cfe-dev] Clang builtins for C++20 STL features

[James Y Knight via cfe-dev]

On Fri, Dec 14, 2018 at 12:32 PM JF Bastien <jfbastien at apple.com> wrote:

It was *one of* the understood implementation strategies. Another was
> specific HW support, and yet another was the compiler just always “doing
> the right thing” w.r.t. padding (which is the approach you seem to want to
> take).


The approach I'm in favor of is not a viable strategy for implementing the
paper's changes, because it'd violate the new requirement that padding must
be ignored. Rather, I believe that if the implementation "does the right
thing" with padding, the need to make the standards change in the first
place is greatly reduced. Where by "does the right thing", I mean "does
what C specifies": padding bits may mutate in any arbitrary way upon a
write to a field in an object, (including via struct copy), but cannot just
change out of the blue.

In that world, a compare_exchange_strong on a struct with padding can fail
the first time it's invoked (which would violate the new spec), but can be
guaranteed to succeed the second loop iteration as long as you pass back
the same "expected" pointer. If users could rely on this behavior, I think
it would be sufficient to simply note "Watch out for padding if you do a
compare_exchange operation without a loop around it" -- which is
effectively what the spec said pre-c++20.

Had it been discussed that the example in the R0 paper was not an
> infinite-loop because padding is unspecified during object initialization
> object copies, as the paper suggests is the case?
>
>
> ?
>

The paper gives the impression that the problem it is addressing is that
padding bits are unpredictable when copying or initializing an object --
e.g. that the padding bits in "desired" may be mutated because it's being
passed by value. Both sections 1.1 and the example program in Section 3 --
especially the comments indicating "Padding bits added and removed here"
and "Maybe changed here as well" -- strongly imply that.

However, that is not the major issue -- the contents of padding in the
atomic's object's current state, or in the initial value of "expected"
before entering the loop, or in any copy of "desired" will only cause a
single extra iteration of the loop rather than infinite extra iterations.

Major problems occur only if "expected" can change its memory
representation between being written to as-if by memcpy via the
compare_exchange_strong in the first iteration of the loop, and then being
compared against as-if by memcmp via the compare_exchange_strong in the
second iteration of the loop -- where there are no intervening write
operations occurring on it.

> But, that there is a potential infinite loop only if the C++ standard
> allows the padding bits in "expected" to arbitrarily modify themselves at
> any time between the iterations of the loop, which, unfortunately, it would
> appear to allow?
>
> This is exactly what the paper is addressing, yes.
>

OK. It was not clear from the paper itself that it was intending to address
this issue, rather than the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181219/5a1b4499/attachment.html>