Are volatile data members trivially copyable?

Question

Whilst writing this answer I realised that I'm not as confident about my conclusions as I usually would ensure before hitting Post Your Answer.

I can find a couple of reasonably convincing citations for the argument that the trivial-copyability of volatile data members is either implementation-defined or flat-out disallowed:

• https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/5cWxmw71ktI
• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48118
• http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#496

But I haven't been able to back this up in the standard¹ itself. Particularly "worrying" is that there's no sign of the proposed wording change from that n3159 issues list in the actual standard's final wording.

So, what gives? Are volatile data members trivially copyable, or not?

---

¹   C++11

Paryavi

I just spotted that the proposed wording change in issue #496 is only a month or so old and, as such, post-dates C++11. It is therefore still active. I guess then I'm only asking the same question as Maddock started back in 2004 with #496. – Paryavi

Answer 1

I'm seeing the following definition for "trivially copyable" (C++11 §3.9, paragraph 9):

...Scalar types, trivially copyable class types, arrays of such types, and cv-qualified versions of these types are collectively called trivially copyable types....

cv-qualified by definition includes const and/or volatile (§3.9.3). It would therefore appear that volatile values are explicitly trivially copyable, if the unqualified type would be trivially copyable (a scalar or trivially copyable class type, or array thereof).

Hesta

But look at issue #496 which suggests that this wording is inaccurate and possibly at odds with wording elsewhere. The passage you cite is singled out explicitly there. – Paryavi

@LightnessRacesinOrbit: volatile in C++ is rather different than in, say, Java. I haven't seen where it implies atomicity in C++, and would therefore assume it doesn't. That's the only interpretation i can come up with that is consistent with the rest of the standard. – Hesta

Except committee members evidently disagree, making this inconclusive. Hence my question :( The problem is that, while the standard doesn't guarantee atomicity for volatile objects, it is arguably sufficiently vague about any property of volatile objects as to imply implementation-definedness for most of them. I think that's where Maddock was coming from. I'm actually half-anticipating a DR at this point. – Paryavi

Maddock's rationale regarding atomicity, quoted from the active issue: The problem with this is that a volatile qualified type may need to be copied in a specific way (by copying using only atomic operations on multithreaded platforms, for example) in order to avoid the “memory tearing” that may occur with a byte-by-byte copy. Sure, at present, the standard doesn't get itself involved in such things -- but some implementations may need to (see: GCC 4.7, from the original question) and, as such, 3.9/9 would appear to be a defect and thus practically non-binding. Hence #496. – Paryavi

That stuff that would have to be done in order to avoid "memory tearing"...that's the implementation's problem, if it wants to provide such a guarantee. C++ doesn't require it to. (Whether it will in some future version doesn't change the standard today.) Basically all volatile means anyway is that you want to prohibit optimizations that would cache old values. If you rely on any more than that, you'd have to ask the compiler maker what's safe and what's not, and know that you're using implementation-specific behavior. – Hesta

Treating the standard as authoritative doesn't work when it's self-contradictory. I agree it doesn't appear to be explicitly so in this case (which is not to say that it hasn't happened before) but I do believe there is some doubt, otherwise why would there be an active issue over it at all? Are we to conclude, categorically, that vendors are deliberately breaking compliance over this issue for no reason? Obeying the letter of the standard only gets you so far as can be used in practice and the implication here would seem to be that practice has spat this passage back out. – Paryavi

And DRs apply to the current standard, not the next one. – Paryavi

I'd say "active" is overstating just a tiny bit; according to your link, it was last brought up in a meeting in 2005. The doubt is because people misunderstand volatile and assume it is (or would like it to be) more than it is (probably due to other languages making much stronger guarantees about it than C++ does). Compiler makers are probably trying to add these additional semantics, because too many of their customers think that's what volatile means, and they'd rather be non-compliant than have a compiler that is actually correct but looks "broken" because of users' misconceptions. – Hesta

Huh? There's a wording proposal from last month. – Paryavi

That's not listed in your link; the document i get is dated 2010. Do you have some place where we can see the proposal? – Hesta

It was linked to from the comp.std.c++ thread. It is true that my direct link was accidentally to an older version, but I edited that in my question some two hours ago! Please do follow all of the information presented behind all three links. – Paryavi

I had the old version up...didn't see that you'd edited the link. :P Anyway, whoever proposed the wording change is ascribing semantics to volatile that simply are not, and never really have been, there in C++. Once you start talking about "special hardware instructions" and other such nonsense, you've stepped outside C++'s definition for the word. volatile does not mean "atomic" or "synchronized", and needs no special instructions in order to work. If they want to strengthen the standard definition, fine...but the proposed change is basically sneaking it in through the back door. – Hesta

Answer 2

The answer has been changed by defect reports CWG496 and CWG2094. The latter DR reverts the former.

Now, for a volatile non-static data member,

• if the member is of a scalar type or possibly multidimentional array there of, doesn't make the class non-trivially-copyable, however
• if the member of is of a class type or possibly multidimentional array there of, the implictly declared copy/move functions of the containing class are all deleted, which makes the class non-trivially copyable (since CWG1734).

Consider