Tweak atomic and atomic_ref to match specification's constructor requirements
#219
Conversation
wmaxey
force-pushed
the
bugfix/atomic_copy_ctor
branch
from
68e199b to
89847ef
Compare
… ctor to match specification
wmaxey
force-pushed
the
bugfix/atomic_copy_ctor
branch
from
89847ef to
ab88964
Compare
| @@ -1245,6 +1245,7 @@ struct __atomic_base { | |||
| mutable __cxx_atomic_impl<_Tp, _Sco> __a_; | |||
|
|
|||
| __atomic_base() = default; | |||
| __atomic_base(const __atomic_base&) = delete; | |||
There was a problem hiding this comment.
What about copy assignment? We should probably just rule of 0 it here and be explicit about the move ctor/assignment too?
There was a problem hiding this comment.
Good catch, seems like we've also lost that at some point (probably also in the refactor?).
@wmaxey seems like upstream deletes assignments directly in atomic and we don't, but I guess doing it in the base class is fine too?
There was a problem hiding this comment.
My thought process was: __atomic_base implements the behavior that atomic should inherit. This way if we 'rule of zero' atomic we should get the correct behavior.
We just don't have tests enforcing that bit of the standard so it was missed. 👎
|
I've updated this to refine the constructors for move, and I'm intentionally ignoring |
wmaxey
force-pushed
the
bugfix/atomic_copy_ctor
branch
from
7cf86dc to
8169019
Compare
wmaxey
added
the
testing: internal ci in progress
wmaxey
added
testing: internal ci passed
This is a bugfix to
atomicas the previous refactor removed the deleted constructor and instead allows some internal machinery to create a default copy ctor forcuda::std::atomic.This also adds a test to enforce this conformance.