[basic.exec] - C++17 → C++20

Files changed (1) hide show

tmp/tmpjzizu0jz/{from.md → to.md} +1387 -0

tmp/tmpjzizu0jz/{from.md → to.md} RENAMED Viewed

	@@ -0,0 +1,1387 @@

+## Program execution <a id="basic.exec">[[basic.exec]]</a>
+### Sequential execution <a id="intro.execution">[[intro.execution]]</a>
+An instance of each object with automatic storage duration
+[[basic.stc.auto]] is associated with each entry into its block. Such an
+object exists and retains its last-stored value during the execution of
+the block and while the block is suspended (by a call of a function,
+suspension of a coroutine [[expr.await]], or receipt of a signal).
+A *constituent expression* is defined as follows:
+- The constituent expression of an expression is that expression.
+- The constituent expressions of a *braced-init-list* or of a (possibly
+  parenthesized) *expression-list* are the constituent expressions of
+  the elements of the respective list.
+- The constituent expressions of a *brace-or-equal-initializer* of the
+  form `=` *initializer-clause* are the constituent expressions of the
+  *initializer-clause*.
+[*Example 1*:
+``` cpp
+struct A { int x; };
+struct B { int y; struct A a; };
+B b = { 5, { 1+1 } };
+```
+The constituent expressions of the *initializer* used for the
+initialization of `b` are `5` and `1+1`.
+— *end example*]
+The *immediate subexpressions* of an expression E are
+- the constituent expressions of E’s operands [[expr.prop]],
+- any function call that E implicitly invokes,
+- if E is a *lambda-expression* [[expr.prim.lambda]], the initialization
+  of the entities captured by copy and the constituent expressions of
+  the *initializer* of the *init-capture*s,
+- if E is a function call [[expr.call]] or implicitly invokes a
+  function, the constituent expressions of each default argument
+  [[dcl.fct.default]] used in the call, or
+- if E creates an aggregate object [[dcl.init.aggr]], the constituent
+  expressions of each default member initializer [[class.mem]] used in
+  the initialization.
+A *subexpression* of an expression E is an immediate subexpression of E
+or a subexpression of an immediate subexpression of E.
+[*Note 1*: Expressions appearing in the *compound-statement* of a
+*lambda-expression* are not subexpressions of the
+*lambda-expression*. — *end note*]
+A *full-expression* is
+- an unevaluated operand [[expr.prop]],
+- a *constant-expression* [[expr.const]],
+- an immediate invocation [[expr.const]],
+- an *init-declarator* [[dcl.decl]] or a *mem-initializer*
+  [[class.base.init]], including the constituent expressions of the
+  initializer,
+- an invocation of a destructor generated at the end of the lifetime of
+  an object other than a temporary object [[class.temporary]] whose
+  lifetime has not been extended, or
+- an expression that is not a subexpression of another expression and
+  that is not otherwise part of a full-expression.
+If a language construct is defined to produce an implicit call of a
+function, a use of the language construct is considered to be an
+expression for the purposes of this definition. Conversions applied to
+the result of an expression in order to satisfy the requirements of the
+language construct in which the expression appears are also considered
+to be part of the full-expression. For an initializer, performing the
+initialization of the entity (including evaluating default member
+initializers of an aggregate) is also considered part of the
+full-expression.
+[*Example 2*:
+``` cpp
+struct S {
+  S(int i): I(i) { }            // full-expression is initialization of I
+  int& v() { return I; }
+  ~S() noexcept(false) { }
+private:
+  int I;
+};
+S s1(1);                        // full-expression comprises call of S::S(int)
+void f() {
+  S s2 = 2;                     // full-expression comprises call of S::S(int)
+  if (S(3).v())                 // full-expression includes lvalue-to-rvalue and int to bool conversions,
+                                // performed before temporary is deleted at end of full-expression
+  { }
+  bool b = noexcept(S());       // exception specification of destructor of S considered for noexcept
+  // full-expression is destruction of s2 at end of block
+}
+struct B {
+  B(S = S(0));
+};
+B b[2] = { B(), B() };          // full-expression is the entire initialization
+                                // including the destruction of temporaries
+```
+— *end example*]
+[*Note 2*: The evaluation of a full-expression can include the
+evaluation of subexpressions that are not lexically part of the
+full-expression. For example, subexpressions involved in evaluating
+default arguments [[dcl.fct.default]] are considered to be created in
+the expression that calls the function, not the expression that defines
+the default argument. — *end note*]
+Reading an object designated by a `volatile` glvalue [[basic.lval]],
+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 subexpression) 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 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.
+*Sequenced before* is an asymmetric, transitive, pair-wise relation
+between evaluations executed by a single thread [[intro.multithread]],
+which induces a partial order among those evaluations. Given any two
+evaluations *A* and *B*, if *A* is sequenced before *B* (or,
+equivalently, *B* is *sequenced after* *A*), then the execution of *A*
+shall precede the execution of *B*. If *A* is not sequenced before *B*
+and *B* is not sequenced before *A*, then *A* and *B* are *unsequenced*.
+[*Note 3*: The execution of unsequenced evaluations can
+overlap. — *end note*]
+Evaluations *A* and *B* are *indeterminately sequenced* when either *A*
+is sequenced before *B* or *B* is sequenced before *A*, but it is
+unspecified which.
+[*Note 4*: Indeterminately sequenced evaluations cannot overlap, but
+either could be executed first. — *end note*]
+An expression *X* is said to be sequenced before an expression *Y* if
+every value computation and every side effect associated with the
+expression *X* is sequenced before every value computation and every
+side effect associated with the expression *Y*.
+Every value computation and side effect associated with a
+full-expression is sequenced before every value computation and side
+effect associated with the next full-expression to be evaluated.[^26]
+Except where noted, evaluations of operands of individual operators and
+of subexpressions of individual expressions are unsequenced.
+[*Note 5*: In an expression that is evaluated more than once during the
+execution of a program, unsequenced and indeterminately sequenced
+evaluations of its subexpressions need not be performed consistently in
+different evaluations. — *end note*]
+The value computations of the operands of an operator are sequenced
+before the value computation of the result of the operator. If a side
+effect on a memory location [[intro.memory]] is unsequenced relative to
+either another side effect on the same memory location or a value
+computation using the value of any object in the same memory location,
+and they are not potentially concurrent [[intro.multithread]], the
+behavior is undefined.
+[*Note 6*: The next subclause imposes similar, but more complex
+restrictions on potentially concurrent computations. — *end note*]
+[*Example 3*:
+``` cpp
+void g(int i) {
+  i = 7, i++, i++;              // i becomes 9
+  i = i++ + 1;                  // the value of i is incremented
+  i = i++ + i;                  // undefined behavior
+  i = i + 1;                    // the value of i is incremented
+}
+```
+— *end example*]
+When calling a function (whether or not the function is inline), every
+value computation and side effect associated with any argument
+expression, or with the postfix expression designating the called
+function, is sequenced before execution of every expression or statement
+in the body of the called function. For each function invocation *F*,
+for every evaluation *A* that occurs within *F* and every evaluation *B*
+that does not occur within *F* but is evaluated on the same thread and
+as part of the same signal handler (if any), either *A* is sequenced
+before *B* or *B* is sequenced before *A*.[^27]
+[*Note 7*: If *A* and *B* would not otherwise be sequenced then they
+are indeterminately sequenced. — *end note*]
+Several contexts in C++ cause evaluation of a function call, even though
+no corresponding function call syntax appears in the translation unit.
+[*Example 4*: Evaluation of a *new-expression* invokes one or more
+allocation and constructor functions; see  [[expr.new]]. For another
+example, invocation of a conversion function [[class.conv.fct]] can
+arise in contexts in which no function call syntax
+appears. — *end example*]
+The sequencing constraints on the execution of the called function (as
+described above) are features of the function calls as evaluated,
+whatever the syntax of the expression that calls the function might be.
+If a signal handler is executed as a result of a call to the
+`std::raise` function, then the execution of the handler is sequenced
+after the invocation of the `std::raise` function and before its return.
+[*Note 8*: When a signal is received for another reason, the execution
+of the signal handler is usually unsequenced with respect to the rest of
+the program. — *end note*]
+### Multi-threaded executions and data races <a id="intro.multithread">[[intro.multithread]]</a>
+A *thread of execution* (also known as a *thread*) is a single flow of
+control within a program, including the initial invocation of a specific
+top-level function, and recursively including every function invocation
+subsequently executed by the thread.
+[*Note 1*: When one thread creates another, the initial call to the
+top-level function of the new thread is executed by the new thread, not
+by the creating thread. — *end note*]
+Every thread in a program can potentially access every object and
+function in a program.[^28] Under a hosted implementation, a C++ program
+can have more than one thread running concurrently. The execution of
+each thread proceeds as defined by the remainder of this document. The
+execution of the entire program consists of an execution of all of its
+threads.
+[*Note 2*: Usually the execution can be viewed as an interleaving of
+all its threads. However, some kinds of atomic operations, for example,
+allow executions inconsistent with a simple interleaving, as described
+below. — *end note*]
+Under a freestanding implementation, it is *implementation-defined*
+whether a program can have more than one thread of execution.
+For a signal handler that is not executed as a result of a call to the
+`std::raise` function, it is unspecified which thread of execution
+contains the signal handler invocation.
+#### Data races <a id="intro.races">[[intro.races]]</a>
+The value of an object visible to a thread T at a particular point is
+the initial value of the object, a value assigned to the object by T, or
+a value assigned to the object by another thread, according to the rules
+below.
+[*Note 1*: In some cases, there may instead be undefined behavior. Much
+of this subclause is motivated by the desire to support atomic
+operations with explicit and detailed visibility constraints. However,
+it also implicitly supports a simpler view for more restricted
+programs. — *end note*]
+Two expression evaluations *conflict* if one of them modifies a memory
+location [[intro.memory]] and the other one reads or modifies the same
+memory location.
+The library defines a number of atomic operations [[atomics]] and
+operations on mutexes [[thread]] that are specially identified as
+synchronization operations. These operations play a special role in
+making assignments in one thread visible to another. A synchronization
+operation on one or more memory locations is either a consume operation,
+an acquire operation, a release operation, or both an acquire and
+release operation. A synchronization operation without an associated
+memory location is a fence and can be either an acquire fence, a release
+fence, or both an acquire and release fence. In addition, there are
+relaxed atomic operations, which are not synchronization operations, and
+atomic read-modify-write operations, which have special characteristics.
+[*Note 2*: For example, a call that acquires a mutex will perform an
+acquire operation on the locations comprising the mutex.
+Correspondingly, a call that releases the same mutex will perform a
+release operation on those same locations. Informally, performing a
+release operation on A forces prior side effects on other memory
+locations to become visible to other threads that later perform a
+consume or an acquire operation on A. “Relaxed” atomic operations are
+not synchronization operations even though, like synchronization
+operations, they cannot contribute to data races. — *end note*]
+All modifications to a particular atomic object M occur in some
+particular total order, called the *modification order* of M.
+[*Note 3*: There is a separate order for each atomic object. There is
+no requirement that these can be combined into a single total order for
+all objects. In general this will be impossible since different threads
+may observe modifications to different objects in inconsistent
+orders. — *end note*]
+A *release sequence* headed by a release operation A on an atomic object
+M is a maximal contiguous sub-sequence of side effects in the
+modification order of M, where the first operation is A, and every
+subsequent operation is an atomic read-modify-write operation.
+Certain library calls *synchronize with* other library calls performed
+by another thread. For example, an atomic store-release synchronizes
+with a load-acquire that takes its value from the store
+[[atomics.order]].
+[*Note 4*: Except in the specified cases, reading a later value does
+not necessarily ensure visibility as described below. Such a requirement
+would sometimes interfere with efficient implementation. — *end note*]
+[*Note 5*: The specifications of the synchronization operations define
+when one reads the value written by another. For atomic objects, the
+definition is clear. All operations on a given mutex occur in a single
+total order. Each mutex acquisition “reads the value written” by the
+last mutex release. — *end note*]
+An evaluation A *carries a dependency* to an evaluation B if
+- the value of A is used as an operand of B, unless:
+  - B is an invocation of any specialization of `std::kill_dependency`
+    [[atomics.order]], or
+  - A is the left operand of a built-in logical (`&&`, see
+    [[expr.log.and]]) or logical (`||`, see  [[expr.log.or]]) operator,
+    or
+  - A is the left operand of a conditional (`?:`, see  [[expr.cond]])
+    operator, or
+  - A is the left operand of the built-in comma (`,`) operator
+    [[expr.comma]];
+  or
+- A writes a scalar object or bit-field M, B reads the value written by
+  A from M, and A is sequenced before B, or
+- for some evaluation X, A carries a dependency to X, and X carries a
+  dependency to B.
+[*Note 6*: “Carries a dependency to” is a subset of “is sequenced
+before”, and is similarly strictly intra-thread. — *end note*]
+An evaluation A is *dependency-ordered before* an evaluation B if
+- A performs a release operation on an atomic object M, and, in another
+  thread, B performs a consume operation on M and reads the value
+  written by A, or
+- for some evaluation X, A is dependency-ordered before X and X carries
+  a dependency to B.
+[*Note 7*: The relation “is dependency-ordered before” is analogous to
+“synchronizes with”, but uses release/consume in place of
+release/acquire. — *end note*]
+An evaluation A *inter-thread happens before* an evaluation B if
+- A synchronizes with B, or
+- A is dependency-ordered before B, or
+- for some evaluation X
+  - A synchronizes with X and X is sequenced before B, or
+  - A is sequenced before X and X inter-thread happens before B, or
+  - A inter-thread happens before X and X inter-thread happens before B.
+[*Note 8*: The “inter-thread happens before” relation describes
+arbitrary concatenations of “sequenced before”, “synchronizes with” and
+“dependency-ordered before” relationships, with two exceptions. The
+first exception is that a concatenation is not permitted to end with
+“dependency-ordered before” followed by “sequenced before”. The reason
+for this limitation is that a consume operation participating in a
+“dependency-ordered before” relationship provides ordering only with
+respect to operations to which this consume operation actually carries a
+dependency. The reason that this limitation applies only to the end of
+such a concatenation is that any subsequent release operation will
+provide the required ordering for a prior consume operation. The second
+exception is that a concatenation is not permitted to consist entirely
+of “sequenced before”. The reasons for this limitation are (1) to permit
+“inter-thread happens before” to be transitively closed and (2) the
+“happens before” relation, defined below, provides for relationships
+consisting entirely of “sequenced before”. — *end note*]
+An evaluation A *happens before* an evaluation B (or, equivalently, B
+*happens after* A) if:
+- A is sequenced before B, or
+- A inter-thread happens before B.
+The implementation shall ensure that no program execution demonstrates a
+cycle in the “happens before” relation.
+[*Note 9*: This cycle would otherwise be possible only through the use
+of consume operations. — *end note*]
+An evaluation A *simply happens before* an evaluation B if either
+- A is sequenced before B, or
+- A synchronizes with B, or
+- A simply happens before X and X simply happens before B.
+[*Note 10*: In the absence of consume operations, the happens before
+and simply happens before relations are identical. — *end note*]
+An evaluation A *strongly happens before* an evaluation D if, either
+- A is sequenced before D, or
+- A synchronizes with D, and both A and D are sequentially consistent
+  atomic operations [[atomics.order]], or
+- there are evaluations B and C such that A is sequenced before B, B
+  simply happens before C, and C is sequenced before D, or
+- there is an evaluation B such that A strongly happens before B, and B
+  strongly happens before D.
+[*Note 11*: Informally, if A strongly happens before B, then A appears
+to be evaluated before B in all contexts. Strongly happens before
+excludes consume operations. — *end note*]
+A *visible side effect* A on a scalar object or bit-field M with respect
+to a value computation B of M satisfies the conditions:
+- A happens before B and
+- there is no other side effect X to M such that A happens before X and
+  X happens before B.
+The value of a non-atomic scalar object or bit-field M, as determined by
+evaluation B, shall be the value stored by the visible side effect A.
+[*Note 12*: If there is ambiguity about which side effect to a
+non-atomic object or bit-field is visible, then the behavior is either
+unspecified or undefined. — *end note*]
+[*Note 13*: This states that operations on ordinary objects are not
+visibly reordered. This is not actually detectable without data races,
+but it is necessary to ensure that data races, as defined below, and
+with suitable restrictions on the use of atomics, correspond to data
+races in a simple interleaved (sequentially consistent)
+execution. — *end note*]
+The value of an atomic object M, as determined by evaluation B, shall be
+the value stored by some side effect A that modifies M, where B does not
+happen before A.
+[*Note 14*: The set of such side effects is also restricted by the rest
+of the rules described here, and in particular, by the coherence
+requirements below. — *end note*]
+If an operation A that modifies an atomic object M happens before an
+operation B that modifies M, then A shall be earlier than B in the
+modification order of M.
+[*Note 15*: This requirement is known as write-write
+coherence. — *end note*]
+If a value computation A of an atomic object M happens before a value
+computation B of M, and A takes its value from a side effect X on M,
+then the value computed by B shall either be the value stored by X or
+the value stored by a side effect Y on M, where Y follows X in the
+modification order of M.
+[*Note 16*: This requirement is known as read-read
+coherence. — *end note*]
+If a value computation A of an atomic object M happens before an
+operation B that modifies M, then A shall take its value from a side
+effect X on M, where X precedes B in the modification order of M.
+[*Note 17*: This requirement is known as read-write
+coherence. — *end note*]
+If a side effect X on an atomic object M happens before a value
+computation B of M, then the evaluation B shall take its value from X or
+from a side effect Y that follows X in the modification order of M.
+[*Note 18*: This requirement is known as write-read
+coherence. — *end note*]
+[*Note 19*: The four preceding coherence requirements effectively
+disallow compiler reordering of atomic operations to a single object,
+even if both operations are relaxed loads. This effectively makes the
+cache coherence guarantee provided by most hardware available to C++
+atomic operations. — *end note*]
+[*Note 20*: The value observed by a load of an atomic depends on the
+“happens before” relation, which depends on the values observed by loads
+of atomics. The intended reading is that there must exist an association
+of atomic loads with modifications they observe that, together with
+suitably chosen modification orders and the “happens before” relation
+derived as described above, satisfy the resulting constraints as imposed
+here. — *end note*]
+Two actions are *potentially concurrent* if
+- they are performed by different threads, or
+- they are unsequenced, at least one is performed by a signal handler,
+  and they are not both performed by the same signal handler invocation.
+The execution of a program contains a *data race* if it contains two
+potentially concurrent conflicting actions, at least one of which is not
+atomic, and neither happens before the other, except for the special
+case for signal handlers described below. Any such data race results in
+undefined behavior.
+[*Note 21*: It can be shown that programs that correctly use mutexes
+and `memory_order::seq_cst` operations to prevent all data races and use
+no other synchronization operations behave as if the operations executed
+by their constituent threads were simply interleaved, with each value
+computation of an object being taken from the last side effect on that
+object in that interleaving. This is normally referred to as “sequential
+consistency”. However, this applies only to data-race-free programs, and
+data-race-free programs cannot observe most program transformations that
+do not change single-threaded program semantics. In fact, most
+single-threaded program transformations continue to be allowed, since
+any program that behaves differently as a result must perform an
+undefined operation. — *end note*]
+Two accesses to the same object of type `volatile std::sig_atomic_t` do
+not result in a data race if both occur in the same thread, even if one
+or more occurs in a signal handler. For each signal handler invocation,
+evaluations performed by the thread invoking a signal handler can be
+divided into two groups A and B, such that no evaluations in B happen
+before evaluations in A, and the evaluations of such
+`volatile std::sig_atomic_t` objects take values as though all
+evaluations in A happened before the execution of the signal handler and
+the execution of the signal handler happened before all evaluations in
+B.
+[*Note 22*: Compiler transformations that introduce assignments to a
+potentially shared memory location that would not be modified by the
+abstract machine are generally precluded by this document, since such an
+assignment might overwrite another assignment by a different thread in
+cases in which an abstract machine execution would not have encountered
+a data race. This includes implementations of data member assignment
+that overwrite adjacent members in separate memory locations. Reordering
+of atomic loads in cases in which the atomics in question may alias is
+also generally precluded, since this may violate the coherence
+rules. — *end note*]
+[*Note 23*: Transformations that introduce a speculative read of a
+potentially shared memory location may not preserve the semantics of the
+C++ program as defined in this document, since they potentially
+introduce a data race. However, they are typically valid in the context
+of an optimizing compiler that targets a specific machine with
+well-defined semantics for data races. They would be invalid for a
+hypothetical machine that is not tolerant of races or provides hardware
+race detection. — *end note*]
+#### Forward progress <a id="intro.progress">[[intro.progress]]</a>
+The implementation may assume that any thread will eventually do one of
+the following:
+- terminate,
+- make a call to a library I/O function,
+- perform an access through a volatile glvalue, or
+- perform a synchronization operation or an atomic operation.
+[*Note 1*: This is intended to allow compiler transformations such as
+removal of empty loops, even when termination cannot be
+proven. — *end note*]
+Executions of atomic functions that are either defined to be lock-free
+[[atomics.flag]] or indicated as lock-free [[atomics.lockfree]] are
+*lock-free executions*.
+- If there is only one thread that is not blocked [[defns.block]] in a
+  standard library function, a lock-free execution in that thread shall
+  complete. \[*Note 2*: Concurrently executing threads may prevent
+  progress of a lock-free execution. For example, this situation can
+  occur with load-locked store-conditional implementations. This
+  property is sometimes termed obstruction-free. — *end note*]
+- When one or more lock-free executions run concurrently, at least one
+  should complete. \[*Note 3*: It is difficult for some implementations
+  to provide absolute guarantees to this effect, since repeated and
+  particularly inopportune interference from other threads may prevent
+  forward progress, e.g., by repeatedly stealing a cache line for
+  unrelated purposes between load-locked and store-conditional
+  instructions. Implementations should ensure that such effects cannot
+  indefinitely delay progress under expected operating conditions, and
+  that such anomalies can therefore safely be ignored by programmers.
+  Outside this document, this property is sometimes termed
+  lock-free. — *end note*]
+During the execution of a thread of execution, each of the following is
+termed an *execution step*:
+- termination of the thread of execution,
+- performing an access through a volatile glvalue, or
+- completion of a call to a library I/O function, a synchronization
+  operation, or an atomic operation.
+An invocation of a standard library function that blocks [[defns.block]]
+is considered to continuously execute execution steps while waiting for
+the condition that it blocks on to be satisfied.
+[*Example 1*: A library I/O function that blocks until the I/O
+operation is complete can be considered to continuously check whether
+the operation is complete. Each such check might consist of one or more
+execution steps, for example using observable behavior of the abstract
+machine. — *end example*]
+[*Note 4*: Because of this and the preceding requirement regarding what
+threads of execution have to perform eventually, it follows that no
+thread of execution can execute forever without an execution step
+occurring. — *end note*]
+A thread of execution *makes progress* when an execution step occurs or
+a lock-free execution does not complete because there are other
+concurrent threads that are not blocked in a standard library function
+(see above).
+For a thread of execution providing *concurrent forward progress
+guarantees*, the implementation ensures that the thread will eventually
+make progress for as long as it has not terminated.
+[*Note 5*: This is required regardless of whether or not other threads
+of executions (if any) have been or are making progress. To eventually
+fulfill this requirement means that this will happen in an unspecified
+but finite amount of time. — *end note*]
+It is *implementation-defined* whether the implementation-created thread
+of execution that executes `main` [[basic.start.main]] and the threads
+of execution created by `std::thread` [[thread.thread.class]] or
+`std::jthread` [[thread.jthread.class]] provide concurrent forward
+progress guarantees.
+[*Note 6*: General-purpose implementations should provide these
+guarantees. — *end note*]
+For a thread of execution providing *parallel forward progress
+guarantees*, the implementation is not required to ensure that the
+thread will eventually make progress if it has not yet executed any
+execution step; once this thread has executed a step, it provides
+concurrent forward progress guarantees.
+[*Note 7*: This does not specify a requirement for when to start this
+thread of execution, which will typically be specified by the entity
+that creates this thread of execution. For example, a thread of
+execution that provides concurrent forward progress guarantees and
+executes tasks from a set of tasks in an arbitrary order, one after the
+other, satisfies the requirements of parallel forward progress for these
+tasks. — *end note*]
+For a thread of execution providing *weakly parallel forward progress
+guarantees*, the implementation does not ensure that the thread will
+eventually make progress.
+[*Note 8*: Threads of execution providing weakly parallel forward
+progress guarantees cannot be expected to make progress regardless of
+whether other threads make progress or not; however, blocking with
+forward progress guarantee delegation, as defined below, can be used to
+ensure that such threads of execution make progress
+eventually. — *end note*]
+Concurrent forward progress guarantees are stronger than parallel
+forward progress guarantees, which in turn are stronger than weakly
+parallel forward progress guarantees.
+[*Note 9*: For example, some kinds of synchronization between threads
+of execution may only make progress if the respective threads of
+execution provide parallel forward progress guarantees, but will fail to
+make progress under weakly parallel guarantees. — *end note*]
+When a thread of execution P is specified to *block with forward
+progress guarantee delegation* on the completion of a set S of threads
+of execution, then throughout the whole time of P being blocked on S,
+the implementation shall ensure that the forward progress guarantees
+provided by at least one thread of execution in S is at least as strong
+as P’s forward progress guarantees.
+[*Note 10*: It is unspecified which thread or threads of execution in S
+are chosen and for which number of execution steps. The strengthening is
+not permanent and not necessarily in place for the rest of the lifetime
+of the affected thread of execution. As long as P is blocked, the
+implementation has to eventually select and potentially strengthen a
+thread of execution in S. — *end note*]
+Once a thread of execution in S terminates, it is removed from S. Once S
+is empty, P is unblocked.
+[*Note 11*: A thread of execution B thus can temporarily provide an
+effectively stronger forward progress guarantee for a certain amount of
+time, due to a second thread of execution A being blocked on it with
+forward progress guarantee delegation. In turn, if B then blocks with
+forward progress guarantee delegation on C, this may also temporarily
+provide a stronger forward progress guarantee to C. — *end note*]
+[*Note 12*: If all threads of execution in S finish executing (e.g.,
+they terminate and do not use blocking synchronization incorrectly),
+then P’s execution of the operation that blocks with forward progress
+guarantee delegation will not result in P’s progress guarantee being
+effectively weakened. — *end note*]
+[*Note 13*: This does not remove any constraints regarding blocking
+synchronization for threads of execution providing parallel or weakly
+parallel forward progress guarantees because the implementation is not
+required to strengthen a particular thread of execution whose too-weak
+progress guarantee is preventing overall progress. — *end note*]
+An implementation should ensure that the last value (in modification
+order) assigned by an atomic or synchronization operation will become
+visible to all other threads in a finite period of time.
+### Start and termination <a id="basic.start">[[basic.start]]</a>
+#### `main` function <a id="basic.start.main">[[basic.start.main]]</a>
+A program shall contain a global function called `main` attached to the
+global module. Executing a program starts a main thread of execution (
+[[intro.multithread]], [[thread.threads]]) in which the `main` function
+is invoked, and in which variables of static storage duration might be
+initialized [[basic.start.static]] and destroyed [[basic.start.term]].
+It is *implementation-defined* whether a program in a freestanding
+environment is required to define a `main` function.
+[*Note 1*: In a freestanding environment, startup and termination is
+*implementation-defined*; startup contains the execution of constructors
+for objects of namespace scope with static storage duration; termination
+contains the execution of destructors for objects with static storage
+duration. — *end note*]
+An implementation shall not predefine the `main` function. This function
+shall not be overloaded. Its type shall have C++ language linkage and it
+shall have a declared return type of type `int`, but otherwise its type
+is *implementation-defined*. An implementation shall allow both
+- a function of `()` returning `int` and
+- a function of `(int`, pointer to pointer to `char)` returning `int`
+as the type of `main` [[dcl.fct]]. In the latter form, for purposes of
+exposition, the first function parameter is called `argc` and the second
+function parameter is called `argv`, where `argc` shall be the number of
+arguments passed to the program from the environment in which the
+program is run. If `argc` is nonzero these arguments shall be supplied
+in `argv[0]` through `argv[argc-1]` as pointers to the initial
+characters of null-terminated multibyte strings (NTMBSs)
+[[multibyte.strings]] and `argv[0]` shall be the pointer to the initial
+character of a NTMBS that represents the name used to invoke the program
+or `""`. The value of `argc` shall be non-negative. The value of
+`argv[argc]` shall be 0.
+[*Note 2*: It is recommended that any further (optional) parameters be
+added after `argv`. — *end note*]
+The function `main` shall not be used within a program. The linkage
+[[basic.link]] of `main` is *implementation-defined*. A program that
+defines `main` as deleted or that declares `main` to be `inline`,
+`static`, or `constexpr` is ill-formed. The function `main` shall not be
+a coroutine [[dcl.fct.def.coroutine]]. The `main` function shall not be
+declared with a *linkage-specification* [[dcl.link]]. A program that
+declares a variable `main` at global scope, or that declares a function
+`main` at global scope attached to a named module, or that declares the
+name `main` with C language linkage (in any namespace) is ill-formed.
+The name `main` is not otherwise reserved.
+[*Example 1*: Member functions, classes, and enumerations can be called
+`main`, as can entities in other namespaces. — *end example*]
+Terminating the program without leaving the current block (e.g., by
+calling the function `std::exit(int)` [[support.start.term]]) does not
+destroy any objects with automatic storage duration [[class.dtor]]. If
+`std::exit` is called to end a program during the destruction of an
+object with static or thread storage duration, the program has undefined
+behavior.
+A `return` statement [[stmt.return]] in `main` has the effect of leaving
+the main function (destroying any objects with automatic storage
+duration) and calling `std::exit` with the return value as the argument.
+If control flows off the end of the *compound-statement* of `main`, the
+effect is equivalent to a `return` with operand `0` (see also
+[[except.handle]]).
+#### Static initialization <a id="basic.start.static">[[basic.start.static]]</a>
+Variables with static storage duration are initialized as a consequence
+of program initiation. Variables with thread storage duration are
+initialized as a consequence of thread execution. Within each of these
+phases of initiation, initialization occurs as follows.
+*Constant initialization* is performed if a variable or temporary object
+with static or thread storage duration is constant-initialized
+[[expr.const]]. If constant initialization is not performed, a variable
+with static storage duration [[basic.stc.static]] or thread storage
+duration [[basic.stc.thread]] is zero-initialized [[dcl.init]].
+Together, zero-initialization and constant initialization are called
+*static initialization*; all other initialization is *dynamic
+initialization*. All static initialization strongly happens before
+[[intro.races]] any dynamic initialization.
+[*Note 1*: The dynamic initialization of non-local variables is
+described in  [[basic.start.dynamic]]; that of local static variables is
+described in  [[stmt.dcl]]. — *end note*]
+An implementation is permitted to perform the initialization of a
+variable with static or thread storage duration as a static
+initialization even if such initialization is not required to be done
+statically, provided that
+- the dynamic version of the initialization does not change the value of
+  any other object of static or thread storage duration prior to its
+  initialization, and
+- the static version of the initialization produces the same value in
+  the initialized variable as would be produced by the dynamic
+  initialization if all variables not required to be initialized
+  statically were initialized dynamically.
+[*Note 2*:
+As a consequence, if the initialization of an object `obj1` refers to an
+object `obj2` of namespace scope potentially requiring dynamic
+initialization and defined later in the same translation unit, it is
+unspecified whether the value of `obj2` used will be the value of the
+fully initialized `obj2` (because `obj2` was statically initialized) or
+will be the value of `obj2` merely zero-initialized. For example,
+``` cpp
+inline double fd() { return 1.0; }
+extern double d1;
+double d2 = d1;     // unspecified:
+                    // may be statically initialized to 0.0 or
+                    // dynamically initialized to 0.0 if d1 is
+                    // dynamically initialized, or 1.0 otherwise
+double d1 = fd();   // may be initialized statically or dynamically to 1.0
+```
+— *end note*]
+#### Dynamic initialization of non-local variables <a id="basic.start.dynamic">[[basic.start.dynamic]]</a>
+Dynamic initialization of a non-local variable with static storage
+duration is unordered if the variable is an implicitly or explicitly
+instantiated specialization, is partially-ordered if the variable is an
+inline variable that is not an implicitly or explicitly instantiated
+specialization, and otherwise is ordered.
+[*Note 1*: An explicitly specialized non-inline static data member or
+variable template specialization has ordered
+initialization. — *end note*]
+A declaration `D` is *appearance-ordered* before a declaration `E` if
+- `D` appears in the same translation unit as `E`, or
+- the translation unit containing `E` has an interface dependency on the
+  translation unit containing `D`,
+in either case prior to `E`.
+Dynamic initialization of non-local variables `V` and `W` with static
+storage duration are ordered as follows:
+- If `V` and `W` have ordered initialization and the definition of `V`
+  is appearance-ordered before the definition of `W`, or if `V` has
+  partially-ordered initialization, `W` does not have unordered
+  initialization, and for every definition `E` of `W` there exists a
+  definition `D` of `V` such that `D` is appearance-ordered before `E`,
+  then
+  - if the program does not start a thread [[intro.multithread]] other
+    than the main thread [[basic.start.main]] or `V` and `W` have
+    ordered initialization and they are defined in the same translation
+    unit, the initialization of `V` is sequenced before the
+    initialization of `W`;
+  - otherwise, the initialization of `V` strongly happens before the
+    initialization of `W`.
+- Otherwise, if the program starts a thread other than the main thread
+  before either `V` or `W` is initialized, it is unspecified in which
+  threads the initializations of `V` and `W` occur; the initializations
+  are unsequenced if they occur in the same thread.
+- Otherwise, the initializations of `V` and `W` are indeterminately
+  sequenced.
+[*Note 2*: This definition permits initialization of a sequence of
+ordered variables concurrently with another sequence. — *end note*]
+A *non-initialization odr-use* is an odr-use [[basic.def.odr]] not
+caused directly or indirectly by the initialization of a non-local
+static or thread storage duration variable.
+It is *implementation-defined* whether the dynamic initialization of a
+non-local non-inline variable with static storage duration is sequenced
+before the first statement of `main` or is deferred. If it is deferred,
+it strongly happens before any non-initialization odr-use of any
+non-inline function or non-inline variable defined in the same
+translation unit as the variable to be initialized. [^29] It is
+*implementation-defined* in which threads and at which points in the
+program such deferred dynamic initialization occurs.
+[*Note 3*: Such points should be chosen in a way that allows the
+programmer to avoid deadlocks. — *end note*]
+[*Example 1*:
+``` cpp
+// - File 1 -
+#include "a.h"
+#include "b.h"
+B b;
+A::A(){
+  b.Use();
+}
+// - File 2 -
+#include "a.h"
+A a;
+// - File 3 -
+#include "a.h"
+#include "b.h"
+extern A a;
+extern B b;
+int main() {
+  a.Use();
+  b.Use();
+}
+```
+It is *implementation-defined* whether either `a` or `b` is initialized
+before `main` is entered or whether the initializations are delayed
+until `a` is first odr-used in `main`. In particular, if `a` is
+initialized before `main` is entered, it is not guaranteed that `b` will
+be initialized before it is odr-used by the initialization of `a`, that
+is, before `A::A` is called. If, however, `a` is initialized at some
+point after the first statement of `main`, `b` will be initialized prior
+to its use in `A::A`.
+— *end example*]
+It is *implementation-defined* whether the dynamic initialization of a
+non-local inline variable with static storage duration is sequenced
+before the first statement of `main` or is deferred. If it is deferred,
+it strongly happens before any non-initialization odr-use of that
+variable. It is *implementation-defined* in which threads and at which
+points in the program such deferred dynamic initialization occurs.
+It is *implementation-defined* whether the dynamic initialization of a
+non-local non-inline variable with thread storage duration is sequenced
+before the first statement of the initial function of a thread or is
+deferred. If it is deferred, the initialization associated with the
+entity for thread *t* is sequenced before the first non-initialization
+odr-use by *t* of any non-inline variable with thread storage duration
+defined in the same translation unit as the variable to be initialized.
+It is *implementation-defined* in which threads and at which points in
+the program such deferred dynamic initialization occurs.
+If the initialization of a non-local variable with static or thread
+storage duration exits via an exception, the function `std::terminate`
+is called [[except.terminate]].
+#### Termination <a id="basic.start.term">[[basic.start.term]]</a>
+Constructed objects [[dcl.init]] with static storage duration are
+destroyed and functions registered with `std::atexit` are called as part
+of a call to `std::exit` [[support.start.term]]. The call to `std::exit`
+is sequenced before the destructions and the registered functions.
+[*Note 1*: Returning from `main` invokes `std::exit`
+[[basic.start.main]]. — *end note*]
+Constructed objects with thread storage duration within a given thread
+are destroyed as a result of returning from the initial function of that
+thread and as a result of that thread calling `std::exit`. The
+destruction of all constructed objects with thread storage duration
+within that thread strongly happens before destroying any object with
+static storage duration.
+If the completion of the constructor or dynamic initialization of an
+object with static storage duration strongly happens before that of
+another, the completion of the destructor of the second is sequenced
+before the initiation of the destructor of the first. If the completion
+of the constructor or dynamic initialization of an object with thread
+storage duration is sequenced before that of another, the completion of
+the destructor of the second is sequenced before the initiation of the
+destructor of the first. If an object is initialized statically, the
+object is destroyed in the same order as if the object was dynamically
+initialized. For an object of array or class type, all subobjects of
+that object are destroyed before any block-scope object with static
+storage duration initialized during the construction of the subobjects
+is destroyed. If the destruction of an object with static or thread
+storage duration exits via an exception, the function `std::terminate`
+is called [[except.terminate]].
+If a function contains a block-scope object of static or thread storage
+duration that has been destroyed and the function is called during the
+destruction of an object with static or thread storage duration, the
+program has undefined behavior if the flow of control passes through the
+definition of the previously destroyed block-scope object. Likewise, the
+behavior is undefined if the block-scope object is used indirectly
+(i.e., through a pointer) after its destruction.
+If the completion of the initialization of an object with static storage
+duration strongly happens before a call to `std::atexit` (see
+`<cstdlib>`, [[support.start.term]]), the call to the function passed to
+`std::atexit` is sequenced before the call to the destructor for the
+object. If a call to `std::atexit` strongly happens before the
+completion of the initialization of an object with static storage
+duration, the call to the destructor for the object is sequenced before
+the call to the function passed to `std::atexit`. If a call to
+`std::atexit` strongly happens before another call to `std::atexit`, the
+call to the function passed to the second `std::atexit` call is
+sequenced before the call to the function passed to the first
+`std::atexit` call.
+If there is a use of a standard library object or function not permitted
+within signal handlers [[support.runtime]] that does not happen before
+[[intro.multithread]] completion of destruction of objects with static
+storage duration and execution of `std::atexit` registered functions
+[[support.start.term]], the program has undefined behavior.
+[*Note 2*: If there is a use of an object with static storage duration
+that does not happen before the object’s destruction, the program has
+undefined behavior. Terminating every thread before a call to
+`std::exit` or the exit from `main` is sufficient, but not necessary, to
+satisfy these requirements. These requirements permit thread managers as
+static-storage-duration objects. — *end note*]
+Calling the function `std::abort()` declared in `<cstdlib>` terminates
+the program without executing any destructors and without calling the
+functions passed to `std::atexit()` or `std::at_quick_exit()`.
+<!-- Link reference definitions -->
+[allocator.members]: utilities.md#allocator.members
+[allocator.traits.members]: utilities.md#allocator.traits.members
+[atomics]: atomics.md#atomics
+[atomics.flag]: atomics.md#atomics.flag
+[atomics.lockfree]: atomics.md#atomics.lockfree
+[atomics.order]: atomics.md#atomics.order
+[bad.alloc]: support.md#bad.alloc
+[basic]: #basic
+[basic.align]: #basic.align
+[basic.compound]: #basic.compound
+[basic.def]: #basic.def
+[basic.def.odr]: #basic.def.odr
+[basic.exec]: #basic.exec
+[basic.fundamental]: #basic.fundamental
+[basic.fundamental.width]: #basic.fundamental.width
+[basic.funscope]: #basic.funscope
+[basic.indet]: #basic.indet
+[basic.life]: #basic.life
+[basic.link]: #basic.link
+[basic.lookup]: #basic.lookup
+[basic.lookup.argdep]: #basic.lookup.argdep
+[basic.lookup.classref]: #basic.lookup.classref
+[basic.lookup.elab]: #basic.lookup.elab
+[basic.lookup.qual]: #basic.lookup.qual
+[basic.lookup.udir]: #basic.lookup.udir
+[basic.lookup.unqual]: #basic.lookup.unqual
+[basic.lval]: expr.md#basic.lval
+[basic.memobj]: #basic.memobj
+[basic.namespace]: dcl.md#basic.namespace
+[basic.pre]: #basic.pre
+[basic.scope]: #basic.scope
+[basic.scope.block]: #basic.scope.block
+[basic.scope.class]: #basic.scope.class
+[basic.scope.declarative]: #basic.scope.declarative
+[basic.scope.enum]: #basic.scope.enum
+[basic.scope.hiding]: #basic.scope.hiding
+[basic.scope.namespace]: #basic.scope.namespace
+[basic.scope.param]: #basic.scope.param
+[basic.scope.pdecl]: #basic.scope.pdecl
+[basic.scope.temp]: #basic.scope.temp
+[basic.start]: #basic.start
+[basic.start.dynamic]: #basic.start.dynamic
+[basic.start.main]: #basic.start.main
+[basic.start.static]: #basic.start.static
+[basic.start.term]: #basic.start.term
+[basic.stc]: #basic.stc
+[basic.stc.auto]: #basic.stc.auto
+[basic.stc.dynamic]: #basic.stc.dynamic
+[basic.stc.dynamic.allocation]: #basic.stc.dynamic.allocation
+[basic.stc.dynamic.deallocation]: #basic.stc.dynamic.deallocation
+[basic.stc.dynamic.safety]: #basic.stc.dynamic.safety
+[basic.stc.inherit]: #basic.stc.inherit
+[basic.stc.static]: #basic.stc.static
+[basic.stc.thread]: #basic.stc.thread
+[basic.type.qualifier]: #basic.type.qualifier
+[basic.type.qualifier.rel]: #basic.type.qualifier.rel
+[basic.types]: #basic.types
+[bit.cast]: numerics.md#bit.cast
+[c.malloc]: utilities.md#c.malloc
+[class]: class.md#class
+[class.abstract]: class.md#class.abstract
+[class.access]: class.md#class.access
+[class.base.init]: class.md#class.base.init
+[class.bit]: class.md#class.bit
+[class.cdtor]: class.md#class.cdtor
+[class.conv.fct]: class.md#class.conv.fct
+[class.copy.assign]: class.md#class.copy.assign
+[class.copy.ctor]: class.md#class.copy.ctor
+[class.copy.elision]: class.md#class.copy.elision
+[class.default.ctor]: class.md#class.default.ctor
+[class.derived]: class.md#class.derived
+[class.dtor]: class.md#class.dtor
+[class.free]: class.md#class.free
+[class.friend]: class.md#class.friend
+[class.local]: class.md#class.local
+[class.mem]: class.md#class.mem
+[class.member.lookup]: class.md#class.member.lookup
+[class.mfct]: class.md#class.mfct
+[class.mfct.non-static]: class.md#class.mfct.non-static
+[class.name]: class.md#class.name
+[class.nest]: class.md#class.nest
+[class.pre]: class.md#class.pre
+[class.prop]: class.md#class.prop
+[class.qual]: #class.qual
+[class.spaceship]: class.md#class.spaceship
+[class.static]: class.md#class.static
+[class.static.data]: class.md#class.static.data
+[class.temporary]: #class.temporary
+[class.this]: class.md#class.this
+[class.union]: class.md#class.union
+[class.virtual]: class.md#class.virtual
+[conv]: expr.md#conv
+[conv.array]: expr.md#conv.array
+[conv.func]: expr.md#conv.func
+[conv.integral]: expr.md#conv.integral
+[conv.lval]: expr.md#conv.lval
+[conv.mem]: expr.md#conv.mem
+[conv.prom]: expr.md#conv.prom
+[conv.ptr]: expr.md#conv.ptr
+[conv.rank]: #conv.rank
+[conv.rval]: expr.md#conv.rval
+[cpp.predefined]: cpp.md#cpp.predefined
+[cstddef.syn]: support.md#cstddef.syn
+[cstring.syn]: strings.md#cstring.syn
+[dcl.align]: dcl.md#dcl.align
+[dcl.array]: dcl.md#dcl.array
+[dcl.attr]: dcl.md#dcl.attr
+[dcl.attr.nouniqueaddr]: dcl.md#dcl.attr.nouniqueaddr
+[dcl.constexpr]: dcl.md#dcl.constexpr
+[dcl.dcl]: dcl.md#dcl.dcl
+[dcl.decl]: dcl.md#dcl.decl
+[dcl.enum]: dcl.md#dcl.enum
+[dcl.fct]: dcl.md#dcl.fct
+[dcl.fct.def]: dcl.md#dcl.fct.def
+[dcl.fct.def.coroutine]: dcl.md#dcl.fct.def.coroutine
+[dcl.fct.def.general]: dcl.md#dcl.fct.def.general
+[dcl.fct.default]: dcl.md#dcl.fct.default
+[dcl.init]: dcl.md#dcl.init
+[dcl.init.aggr]: dcl.md#dcl.init.aggr
+[dcl.init.list]: dcl.md#dcl.init.list
+[dcl.init.ref]: dcl.md#dcl.init.ref
+[dcl.inline]: dcl.md#dcl.inline
+[dcl.link]: dcl.md#dcl.link
+[dcl.meaning]: dcl.md#dcl.meaning
+[dcl.mptr]: dcl.md#dcl.mptr
+[dcl.name]: dcl.md#dcl.name
+[dcl.pre]: dcl.md#dcl.pre
+[dcl.ptr]: dcl.md#dcl.ptr
+[dcl.ref]: dcl.md#dcl.ref
+[dcl.spec]: dcl.md#dcl.spec
+[dcl.spec.auto]: dcl.md#dcl.spec.auto
+[dcl.stc]: dcl.md#dcl.stc
+[dcl.struct.bind]: dcl.md#dcl.struct.bind
+[dcl.type.elab]: dcl.md#dcl.type.elab
+[dcl.typedef]: dcl.md#dcl.typedef
+[defns.block]: intro.md#defns.block
+[defns.signature]: intro.md#defns.signature
+[defns.signature.templ]: intro.md#defns.signature.templ
+[depr.local]: future.md#depr.local
+[depr.static.constexpr]: future.md#depr.static.constexpr
+[diff.cpp11.basic]: compatibility.md#diff.cpp11.basic
+[enum.udecl]: dcl.md#enum.udecl
+[except.handle]: except.md#except.handle
+[except.pre]: except.md#except.pre
+[except.spec]: except.md#except.spec
+[except.terminate]: except.md#except.terminate
+[except.throw]: except.md#except.throw
+[expr]: expr.md#expr
+[expr.add]: expr.md#expr.add
+[expr.alignof]: expr.md#expr.alignof
+[expr.arith.conv]: expr.md#expr.arith.conv
+[expr.ass]: expr.md#expr.ass
+[expr.await]: expr.md#expr.await
+[expr.call]: expr.md#expr.call
+[expr.cast]: expr.md#expr.cast
+[expr.comma]: expr.md#expr.comma
+[expr.compound]: expr.md#expr.compound
+[expr.cond]: expr.md#expr.cond
+[expr.const]: expr.md#expr.const
+[expr.const.cast]: expr.md#expr.const.cast
+[expr.context]: expr.md#expr.context
+[expr.delete]: expr.md#expr.delete
+[expr.dynamic.cast]: expr.md#expr.dynamic.cast
+[expr.eq]: expr.md#expr.eq
+[expr.log.and]: expr.md#expr.log.and
+[expr.log.or]: expr.md#expr.log.or
+[expr.mptr.oper]: expr.md#expr.mptr.oper
+[expr.new]: expr.md#expr.new
+[expr.pre]: expr.md#expr.pre
+[expr.prim.id]: expr.md#expr.prim.id
+[expr.prim.id.dtor]: expr.md#expr.prim.id.dtor
+[expr.prim.id.qual]: expr.md#expr.prim.id.qual
+[expr.prim.lambda]: expr.md#expr.prim.lambda
+[expr.prim.lambda.capture]: expr.md#expr.prim.lambda.capture
+[expr.prim.lambda.closure]: expr.md#expr.prim.lambda.closure
+[expr.prim.this]: expr.md#expr.prim.this
+[expr.prop]: expr.md#expr.prop
+[expr.ref]: expr.md#expr.ref
+[expr.reinterpret.cast]: expr.md#expr.reinterpret.cast
+[expr.rel]: expr.md#expr.rel
+[expr.sizeof]: expr.md#expr.sizeof
+[expr.static.cast]: expr.md#expr.static.cast
+[expr.sub]: expr.md#expr.sub
+[expr.type.conv]: expr.md#expr.type.conv
+[expr.typeid]: expr.md#expr.typeid
+[expr.unary.op]: expr.md#expr.unary.op
+[get.new.handler]: support.md#get.new.handler
+[headers]: library.md#headers
+[intro.execution]: #intro.execution
+[intro.memory]: #intro.memory
+[intro.multithread]: #intro.multithread
+[intro.object]: #intro.object
+[intro.progress]: #intro.progress
+[intro.races]: #intro.races
+[lex.charset]: lex.md#lex.charset
+[lex.name]: lex.md#lex.name
+[lex.separate]: lex.md#lex.separate
+[locale]: localization.md#locale
+[meta.trans.other]: utilities.md#meta.trans.other
+[module.context]: module.md#module.context
+[module.global.frag]: module.md#module.global.frag
+[module.import]: module.md#module.import
+[module.interface]: module.md#module.interface
+[module.reach]: module.md#module.reach
+[module.unit]: module.md#module.unit
+[multibyte.strings]: library.md#multibyte.strings
+[namespace.def]: dcl.md#namespace.def
+[namespace.memdef]: dcl.md#namespace.memdef
+[namespace.qual]: #namespace.qual
+[namespace.udecl]: dcl.md#namespace.udecl
+[namespace.udir]: dcl.md#namespace.udir
+[new.delete]: support.md#new.delete
+[new.delete.array]: support.md#new.delete.array
+[new.delete.placement]: support.md#new.delete.placement
+[new.delete.single]: support.md#new.delete.single
+[new.handler]: support.md#new.handler
+[over]: over.md#over
+[over.literal]: over.md#over.literal
+[over.match]: over.md#over.match
+[over.oper]: over.md#over.oper
+[over.over]: over.md#over.over
+[ptr.align]: utilities.md#ptr.align
+[ptr.launder]: support.md#ptr.launder
+[replacement.functions]: library.md#replacement.functions
+[special]: class.md#special
+[stmt.block]: stmt.md#stmt.block
+[stmt.dcl]: stmt.md#stmt.dcl
+[stmt.expr]: stmt.md#stmt.expr
+[stmt.goto]: stmt.md#stmt.goto
+[stmt.if]: stmt.md#stmt.if
+[stmt.label]: stmt.md#stmt.label
+[stmt.ranged]: stmt.md#stmt.ranged
+[stmt.return]: stmt.md#stmt.return
+[support.dynamic]: support.md#support.dynamic
+[support.limits]: support.md#support.limits
+[support.runtime]: support.md#support.runtime
+[support.start.term]: support.md#support.start.term
+[support.types]: support.md#support.types
+[temp.deduct.guide]: temp.md#temp.deduct.guide
+[temp.dep]: temp.md#temp.dep
+[temp.dep.candidate]: temp.md#temp.dep.candidate
+[temp.expl.spec]: temp.md#temp.expl.spec
+[temp.explicit]: temp.md#temp.explicit
+[temp.local]: temp.md#temp.local
+[temp.names]: temp.md#temp.names
+[temp.nondep]: temp.md#temp.nondep
+[temp.over]: temp.md#temp.over
+[temp.param]: temp.md#temp.param
+[temp.point]: temp.md#temp.point
+[temp.pre]: temp.md#temp.pre
+[temp.res]: temp.md#temp.res
+[temp.spec]: temp.md#temp.spec
+[temp.type]: temp.md#temp.type
+[thread]: thread.md#thread
+[thread.jthread.class]: thread.md#thread.jthread.class
+[thread.thread.class]: thread.md#thread.thread.class
+[thread.threads]: thread.md#thread.threads
+[util.dynamic.safety]: utilities.md#util.dynamic.safety
+[^1]: Appearing inside the brace-enclosed *declaration-seq* in a
+    *linkage-specification* does not affect whether a declaration is a
+    definition.
+[^2]: An implementation is not required to call allocation and
+    deallocation functions from constructors or destructors; however,
+    this is a permissible implementation technique.
+[^3]: This refers to unqualified names that occur, for instance, in a
+    type or default argument in the *parameter-declaration-clause* or
+    used in the function body.
+[^4]: This refers to unqualified names following the class name; such a
+    name may be used in a *base-specifier* or in the
+    *member-specification* of the class definition.
+[^5]: This lookup applies whether the definition of `X` is nested within
+    `Y`’s definition or whether `X`’s definition appears in a namespace
+    scope enclosing `Y`’s definition [[class.nest]].
+[^6]: That is, an unqualified name that occurs, for instance, in a type
+    in the *parameter-declaration-clause* or in the
+    *noexcept-specifier*.
+[^7]: This lookup applies whether the member function is defined within
+    the definition of class `X` or whether the member function is
+    defined in a namespace scope enclosing `X`’s definition.
+[^8]: Lookups in which function names are ignored include names
+    appearing in a *nested-name-specifier*, an
+    *elaborated-type-specifier*, or a *base-specifier*.
+[^9]: The number of bits in a byte is reported by the macro `CHAR_BIT`
+    in the header `<climits>`.
+[^10]: Under the “as-if” rule an implementation is allowed to store two
+    objects at the same machine address or not store an object at all if
+    the program cannot observe the difference [[intro.execution]].
+[^11]: For example, before the construction of a global object that is
+    initialized via a user-provided constructor [[class.cdtor]].
+[^12]: That is, an object for which a destructor will be called
+    implicitly—upon exit from the block for an object with automatic
+    storage duration, upon exit from the thread for an object with
+    thread storage duration, or upon exit from the program for an object
+    with static storage duration.
+[^13]: Some implementations might define that copying an invalid pointer
+    value causes a system-generated runtime fault.
+[^14]: The intent is to have `operator new()` implementable by calling
+    `std::malloc()` or `std::calloc()`, so the rules are substantially
+    the same. C++ differs from C in requiring a zero request to return a
+    non-null pointer.
+[^15]: The global `operator delete(void*, std::size_t)` precludes use of
+    an allocation function `void operator new(std::size_t, std::size_t)`
+    as a placement allocation function ([[diff.cpp11.basic]]).
+[^16]: This subclause does not impose restrictions on indirection
+    through pointers to memory not allocated by `::operator new`. This
+    maintains the ability of many C++ implementations to use binary
+    libraries and components written in other languages. In particular,
+    this applies to C binaries, because indirection through pointers to
+    memory allocated by `std::malloc` is not restricted.
+[^17]: The same rules apply to initialization of an `initializer_list`
+    object [[dcl.init.list]] with its underlying temporary array.
+[^18]: By using, for example, the library functions [[headers]]
+    `std::memcpy` or `std::memmove`.
+[^19]: By using, for example, the library functions [[headers]]
+    `std::memcpy` or `std::memmove`.
+[^20]: The intent is that the memory model of C++ is compatible with
+    that of ISO/IEC 9899 Programming Language C.
+[^21]: The size and layout of an instance of an incompletely-defined
+    object type is unknown.
+[^22]: This is also known as two’s complement representation.
+[^23]: Static class members are objects or functions, and pointers to
+    them are ordinary pointers to objects or functions.
+[^24]: For an object that is not within its lifetime, this is the first
+    byte in memory that it will occupy or used to occupy.
+[^25]: The same representation and alignment requirements are meant to
+    imply interchangeability as arguments to functions, return values
+    from functions, and non-static data members of unions.
+[^26]: As specified in  [[class.temporary]], after a full-expression is
+    evaluated, a sequence of zero or more invocations of destructor
+    functions for temporary objects takes place, usually in reverse
+    order of the construction of each temporary object.
+[^27]: In other words, function executions do not interleave with each
+    other.
+[^28]: An object with automatic or thread storage duration [[basic.stc]]
+    is associated with one specific thread, and can be accessed by a
+    different thread only indirectly through a pointer or reference
+    [[basic.compound]].
+[^29]: A non-local variable with static storage duration having
+    initialization with side effects is initialized in this case, even
+    if it is not itself odr-used ([[basic.def.odr]],
+    [[basic.stc.static]]).

Diff to HTML by rtfpessoa