ISO/IEC JTC1 SC22 WG21 P0612R0
Group: WG21
Jens Maurer
2017-02-27

P0612R0: NB comment CH 2: volatile

Change in 1.9 [intro.execution] paragraph 8:
The least requirements on a conforming implementation are:
Change in 1.9 [intro.execution] paragraph 12:
Reading an object designated by a volatile glvalue (3.10), modifying an object, calling a library I/O function, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression (or a sub-expression) in general includes both value computations (including determining the identity of an object for glvalue evaluation and fetching a value previously assigned to an object for prvalue evaluation) and initiation of side effects. When a call to a library I/O function returns or an access to a volatile object through a volatile glvalue is evaluated the side effect is considered complete, even though some external actions implied by the call (such as the I/O itself) or by the volatile access may not have completed yet.
Change in 1.10.2 [intro.progress] paragraph 1:
The implementation may assume that any thread will eventually do one of the following: [ Note: ... ]
Change in 1.10.2 [intro.progress] paragraph 3:
Change in 7.1.7.1 [dcl.type.cv] paragraph 6:
What constitutes an access to an object that has volatile-qualified type is The semantics of an access through a volatile glvalue are implementation-defined. If an attempt is made to refer to access an object defined with a volatile-qualified type through the use of a non-volatile glvalue with a non-volatile-qualified type, the behavior is undefined.
Drafting note: A volatile member in a class does not prevent the class from having a trivial copy constructor. That means, in particular, that values of such types can be passed in registers. I personally consider this incorrect, but the ABI breakage inherent in changing the direction was considered too severe. See core issues 496 and 2094.