Union with volatile and non-volatile standard layout types

It is legal to use active and non-active members of a union if they are standard layout types e.g. like primitive types as int.

On the other hand it is UB to const_cast-away the volatile of a simple variable and use that variable.

Is it legal (no UB) to use both members of this union?

union VU {
    int nv;
    volatile int v;
};

More formal this should be

union VU {
    struct {
        int v;
    } nv;
    struct {
        volatile int v;
    } v;
};

If by "use both members of this union" you mean attempting to exploit the common initial sequence rules to access a volatile object through a non-volatile glvalue:

union VU {
    struct {
        int v;
    } nv;
    struct {
        volatile int v;
    } v;
};
VU x;
x.v.v = 42;
std::cout << x.nv.v;

the answer is no, it's not legal. [class.mem.general]/26 is actually very clear about this:

> In a standard-layout union with an active member of struct type T1, it is permitted to read a non-static data member m of another union member of struct type T2 provided m is part of the common initial sequence of T1 and T2; the behavior is as if the corresponding member of T1 were nominated. [Example 5: ... ] [Note 10: Reading a volatile object through a glvalue of non-volatile type has undefined behavior ([dcl.type.cv]). — end note]

In the above example, the behaviour of reading x.nv.v is as if the corresponding member of the actually active member were nominated, i.e., it reads the member x.v.v of the active member x.v. Since this is a read of the volatile object x.v.v. through a non-volatile glvalue, the behavior is undefined.

On the other hand if you were to do it the other way around (make x.nv.v active, then read it through x.v.v) then it would be legal; it wouldn't be any different from reading through const_cast<volatile int&>(x.nv.v).

The C99 and later Standards deliberately waive jurisdiction over situations where it would otherwise unambiguously define behavior for some but not all implementations, based upon Implementation-Defined traits.

For example, under C89 the behavior of -16384<<1 was defined unambiguously (and usefully) on two's-complement platforms where neither int nor unsigned had any padding bits or trap representations, but it would have yielded Undefined Behavior on an implementation where the bit pattern associated with 0x8000u would be a trap representation if interpreted as int. Because there may exist implementations where the action could invoke UB, the C99 reclassified such shifts on all implementations under the catch-all term "Undefined Behavior".

The semantics of volatile-qualified objects are Implementation Defined. Most implementations define their semantics in such a way that applying a volatile qualifier to an object that wouldn't "need" one would yield semantics compatible with those where the qualifier was absent, in cases where the latter would be defined. Because it is possible, however, that an implementation might store volatile-qualified objects in a manner completely different from non-qualified objects, and use a bit in a volatile-qualified pointer to indicate which kind of access would be required for the target, it would in turn be possible that using a non-qualified lvalue to access a volatile-qualified object might yield unpredictable effects whether or not behavior would have been defined in the qualifier's absence.

Consequently, the Standard waives jurisdiction over how implementations process code such as yours. Such waiver is not meant to imply that implementations where the defined behavior of volatile qualifier would unambiguously specify the behavior of such constructs shouldn't behave in a manner consistent with that. Nonetheless, because some compilers go out of their way to interpret such waivers of jurisdiction as an invitation to process such constructs nonsensically, such code should be recognized as being suitable for use only with implementations that refrain from such treatment.