<html>
<head>
<title>P0612R0: NB comment CH 2: volatile</title>

<style type="text/css">
  ins { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  del { text-decoration:line-through; background-color:#FFA0A0 }
  strong { font-weight: inherit; color: #2020ff }
  #xins:checked ~ * ins { display:none; visibility:hidden }
  #xdel:checked ~ * del { display:none; visibility:hidden }
</style>

</head>

<body>
<p>
ISO/IEC JTC1 SC22 WG21 P0612R0<br/>
Group: WG21<br/>
Jens Maurer<br>
2017-02-27
</p>

<input type="checkbox" id="xins"/><label for="xins">Hide inserted text</label>
<input type="checkbox" id="xdel"/><label for="xdel">Hide deleted text</label>

<h1>P0612R0: NB comment CH 2: volatile</h1>

Change in 1.9 [intro.execution] paragraph 8:

<blockquote>
The least requirements on a conforming implementation are:
  <ul>

    <li><del>Access to volatile objects</del> <ins>Accesses through
    volatile glvalues</ins> are evaluated strictly according to the
    rules of the abstract machine.</li>

    <li>...</li>
  </ul>

</blockquote>


Change in 1.9 [intro.execution] paragraph 12:

<blockquote>
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 <del>to a volatile
object</del> <ins>through a volatile glvalue</ins> 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.
</blockquote>

Change in 1.10.2 [intro.progress] paragraph 1:

<blockquote>
  The implementation may assume that any thread will eventually do one of the following:
  <ul>
    <li>terminate,</li>
    <li>make a call to a library I/O function,</li>
    <li><del>read or modify a volatile object</del> <ins>perform an access through a volatile glvalue</ins>, or</li>
    <li>perform a synchronization operation or an atomic operation.</li>
  </ul>
  [ Note: ... ]
</blockquote>

Change in 1.10.2 [intro.progress] paragraph 3:

<blockquote>
  <ul>
    During the execution of a thread of execution, each of the
    following is termed an execution step:
    <li>termination of the thread of execution,</li>
    <li><del>access to a volatile object,</del> <ins>performing an
    access through a volatile glvalue,</ins> or</li>
    <li>completion of a call to a library I/O function, a
    synchronization operation, or an atomic operation.</li>
    </ul>
</blockquote>

Change in 7.1.7.1 [dcl.type.cv] paragraph 6:

<blockquote>
<del>What constitutes an access to an object that has
volatile-qualified type is</del> <ins>The semantics of an access
through a volatile glvalue are</ins> implementation-defined. If an attempt
is made to <del>refer to</del> <ins>access</ins> an object defined with a volatile-qualified type
through the use of a <ins>non-volatile</ins> glvalue <del>with a non-volatile-qualified type</del>, the
behavior is undefined.
</blockquote>

<em>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.</em>

</body>
</html>
