-
Notifications
You must be signed in to change notification settings - Fork 185
Tweak atomic
and atomic_ref
to match specification's constructor requirements
#219
Conversation
68e199b
to
89847ef
Compare
… ctor to match specification
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
7cf86dc
to
8169019
Compare
This is a bugfix to
atomic
as 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.