[cfe-dev] curious "apparent" gcc bug that clang seems to get right

John McCall rjmccall at apple.com
Thu Dec 5 14:21:19 PST 2013

On Dec 4, 2013, at 9:58 PM, Joshua Cranmer 🐧 <Pidgeot18 at gmail.com> wrote:
> On 12/4/2013 10:51 PM, reed kotler wrote:
>> I'm not sure myself enough of how, if at all, volatile is inherited into a class from it's members.
>> But the following code, boiled down from some complicated android code is essentially.
>> This same problem happens for gcc x86 and mips.
>> Anyone care to weigh in on a proper reading of the C or C++ standard for this?
> C++11 makes this easier to follow. The case this boils down to is the defaulted copy assignment operator for union like classes:
> The implicitly-defined copy assignment operator for a union X copies the object representation (3.9) of X.
> As a result, the fact that the member y is volatile is completely ignored in C++. C11 is much less clear on the subject, but as far as I can make it, the assignment operator is considered to copy the union object and not the volatile int subobject contained within, although you could easily hide behind section 6.7.3's note that "what constitutes an access to an object that has volatile-qualified type is implementation-defined.”

Yeah, the C standard is pretty vague here, but I think the obvious intent is that an access to the aggregate is simultaneously an access to its members (all of them, in the case of a struct, or just to its active member, in the case of a union), and therefore the portion of that access which touches a volatile member is required to follow volatile semantics, i.e. to actually occur.

Note that the C++ rule differs subtly from the C rule, e.g.:
  union { volatile int x; } z;
z is not itself volatile and therefore does not undergo l-value-to-r-value conversion even in C++11, whereas in C it both undergoes formal conversion and is arguably unoptimizable.

I suppose that, in theory, this interpretation would allow a compiler to remove an unused load of a union containing a volatile member if it can prove that that the active member is not volatile.


More information about the cfe-dev mailing list