N4179
revision of N3999
Jens Maurer
2014-10-10

N4179: Transactional Memory Support for C++: Wording (revision 2)

Jens Maurer, jens.maurer@gmx.net

with other members of the transactional memory study group (SG5), including (in alphabetical order):

Hans Boehm, hboehm@google.com
Justin Gottschlich, justin.e.gottschlich@intel.com
Victor Luchangco, victor.luchangco@oracle.com
Paul McKenney, paulmck@linux.vnet.ibm.com
Maged Michael, maged.michael@gmail.com
Mark Moir, mark.moir@oracle.com
Torvald Riegel, triegel@redhat.com
Michael Scott, scott@cs.rochester.edu
Tatiana Shpeisman, tatiana.shpeisman@intel.com
Michael Spear, spear@cse.lehigh.edu
Michael Wong, michaelw@ca.ibm.com (chair of SG5)

Introduction

This paper presents the current wording proposal (both core and library) for integrating transactional memory support into C++. For motivation and introductory overview, see the predecessor paper N3999 "Standard Wording for Transactional Memory Support for C++".

The companion paper N4180 motivates and explains the additional features that have been integrated since the Rapperswil meeting. Those features still require EWG approval.

The blue markings in the core language section indicate modifications that have been made since (and mostly in response to) the comments put forth in the CWG review teleconference on 2014-09-15.

The blue markings in the library section indicate modifications that have been made since the LWG review in Rapperswil (June 2014). No further LEWG or LWG review has occurred since then.

Changes

Addressed comments from 2014-06-02 review teleconference, clarifying the wording.
Address CWG review comments from Rapperswil:
- allow "synchronizes with" for non-library constructs
- volatile subobjects are tx-unsafe
- remove cross-translation unit safe-by-default
- simplified lambda transaction-safety
- redeclarations can omit transaction_safe
- comparing pointers is unspecified unless tx-safety is the same
Address LWG review comments from Rapperswil:
- added more cross-references in the library section
- prohibit additional tx-safe annotations by library implementations using the same words as for constexpr
- for exception types that support tx cancellation, add notes about required implementation support
- remove rand/srand, because some implementation use global state where accesses are synchronized using a mutex
add implicit conversion from "pointer to transaction_safe member function" to "pointer to member function" (see 4.14)
clarify definition of transaction-safe (defined term)
(EWG approval outstanding) added [[optimize_for_synchronized]] attribute (see section 7.6.6 [dcl.attr.sync])
(EWG approval outstanding) added transaction_safe noinherit for virtual functions (non-viral)
(LEWG approval outstanding) added transaction-safety for all containers and iterator-related functions
(LEWG approval outstanding) added tx_exception
Addressed comments from 2014-09-15 CWG review teleconference
- matching a handler performs transaction-safety conversions
- allow, but do not require transaction_safe on lambdas
- a transaction_safe noinherit function overriding a transaction_safe function is ill-formed
- template argument deduction performs transaction-safety conversions
- allow forming a composite pointer type using a transaction-safety conversion
rename maybe transaction_safe to transaction_safe noinherit

Open issues

Exception handling might call std::terminate, which invokes a terminate handler. That terminate handler is a function pointer not declared transaction_safe, so there is a gap in the specification if std::terminate ends up being called inside an atomic transaction. The intersection of desirable and implementable semantics for this case is still under discussion.
Initialization of variables with static storage duration.
Atomic blocks that do not access shared memory locations should not receive or cause an inter-thread-happens-before edge, i.e. atomic blocks cannot be used as a replacement for fences. [Chandler Carruth in Issaquah (February 2014): this allows to remove hardware-level synchronization cost if the compiler can prove that an atomic block is entirely local.]
At first sight, the math functions from <math.h> (e.g. "sin") are transaction-safe. However, they may need to inspect hardware state such as the current rounding mode that might make them unfit for transactional execution.
add "template specialization or instantiation can be tx-safe even when corresponding member of the template is not"
investigate use of std::function inside transactions
(postponed) Consider describing synchronized blocks entirely as-if taking a global mutex.

Resolved issues

Under which circumstances is a lambda function (implicitly) declared transaction-safe? [It is declared tx-safe if its definition is (directly) safe and all invoked functions are tx-safe.] Do we want to allow an explicit transaction_safe/unsafe annotation? [Yes to the former.]
Is the term "transaction-statement" still ok, or should that be renamed to "atomic-statement", in line with the (new) spelling of the keywords? Telco 2014-03-31: use "atomic block" and "transaction-safe".
Allow conversion of "pointer to transaction-safe member function" to "pointer to member function"
add "transaction_safe noinherit" for virtual functions
std::exception is the base of the exception hierarchy. Should we declare its virtual what() function transaction_safe? [no; instead review definition of derived classes such as length_error] This has serious ripple effects to user code, in particular if that user code is totally unaware of transactions. Telco 2014-08-11 and 2014-09-08: introduce "maybe transaction_safe" for virtual functions, which is not viral, but accepts undefined behavior.
For "composite pointer type" in 5 [expr], address that T might be "pointer to function" (not transaction-safe) vs. "pointer to transaction-safe function". This can be unified to "pointer to function" (not transaction-safe).
Introduce a
```
template<class T>
class tx_exception : exception { ... };
```
with a transaction-safe "what()" function and where "T" can be memcpy'd.

Section 1.10 [intro.multithread] Multi-threaded executions and data races

Add a paragraph to section 1.10 [intro.multithread] after paragraph 8:

The start and the end of each synchronized block or atomic block is a full-expression (1.9 [intro.execution]). A synchronized block (6.x [stmt.sync]) or atomic block (6.x [stmt.tx]) that is not dynamically nested within another synchronized block or atomic block is called an outer block. [ Note: Due to syntactic constraints, blocks cannot overlap unless one is nested within the other. ] There is a global total order of execution for all outer blocks. If, in that total order, T1 is ordered before T2, then the end of T1 synchronizes with the start of T2.

Drafting notes: Together with 1.9p14, the first sentence ensures the appropriate (thread-local) sequencing. Inter-thread ordering is ensured by establishing a synchronizes-with relationship in the last sentence.

Change in 1.10 [intro.multithread] paragraph 10:

Synchronized and atomic blocks as well as certain ~~Certain~~ library calls synchronize with other synchronized blocks, atomic blocks, and library calls performed by another thread.

Change in 1.10 [intro.multithread] paragraph 21, and add a new paragraph following it:

The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. [ Note: It can be shown that programs that correctly use mutexes, synchronized and atomic blocks, 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 ]

[ Note: Due to the constraints on transaction safety (8.4.4 [dcl.fct.def.tx]), the following holds for a data-race-free program: If the start of an atomic block T is sequenced before an evaluation A, A is sequenced before the end of T, and A inter-thread happens before some evaluation B, then the end of T inter-thread happens before B. If an evaluation C inter-thread happens before that evaluation A, then C inter-thread happens before the start of T. These properties in turn imply that in any simple interleaved (sequentially consistent) execution, the operations of each atomic block appear to be contiguous in the interleaving. -- end note ]

Clause 2 [lex] Lexical conventions

In section 2.11 [lex.name] paragraph 2, add noinherit and transaction_safe to the table.

In section 2.12 [lex.key], add the keywords synchronized, atomic_noexcept, atomic_cancel, and atomic_commit to the table.

Clause 4 [conv] Standard conversions

Change in section 4.3 [conv.func] paragraph 1:

An lvalue of function type T can be converted to a prvalue of type "pointer to T." Moreover, an lvalue of type "transaction-safe function" can be converted to a prvalue of type "pointer to function". The result is a pointer to the function. [ Footnote: ... ]

Drafting note: This ensures that overload resolution doesn't perceive dropping the "transaction-safe" as two conversions instead of just one. The same trick was applied for converting unscoped enumerations with fixed underlying type to the promoted underlying type (4.5p4).

Add a new section 4.14 [conv.tx]:

4.14 [conv.tx] Transaction-safety conversion

A prvalue of type "pointer to transaction_safe function" can be converted to a prvalue of type "pointer to function". The result is a pointer to the function. A prvalue of type "pointer to member of type transaction_safe function" can be converted to a prvalue of type "pointer to member of type function". The result points to the member function.

Clause 5 [expr] Expressions

Change in 5 [expr] paragraph 13:

[ Note: ... ] The composite pointer type of two operands p1 and p2 having types T1 and T2, respectively, where at least one is a pointer or pointer to member type or std::nullptr_t, is:

...

if T1 or T2 is "pointer to cv1 void" and the other type is "pointer to cv2 T", "pointer to cv12 void", where cv12 is the union of cv1 and cv2 ;

if T1 is "pointer to transaction_safe function" and T2 is "pointer to function", T2, and vice versa;

...

Change in 5.1.2 [expr.prim.lambda] paragraph 1:

lambda-declarator:
     ( parameter-declaration-clause ) mutable_opt transaction_safe_opt
            exception-specification_opt attribute-specifier-seq_opt trailing-return-type_opt

Change in 5.1.2 [expr.prim.lambda] paragraph 5:

This function call operator or operator template is declared const (9.3.1) if and only if the lambda-expression's parameter-declaration-clause is not followed by mutable. It is neither virtual nor declared volatile. It is declared transaction_safe if and only if the lambda-expression's parameter-declaration-clause is followed by transaction_safe or if, in a non-generic lambda-expression, it has a transaction-safe function definition (8.4.4 [dcl.fct.def.tx]). Any exception-specification specified on a lambda-expression applies to the corresponding function call operator or operator template. ...

Change in 5.1.2 [expr.prim.lambda] paragraph 6:

The closure type for a non-generic lambda-expression with no lambda-capture has a public non-virtual non-explicit const transaction_safe conversion function to pointer to function with C++ language linkage (7.5 [dcl.link]) having the same parameter and return types as the closure type's function call operator. That pointer is a pointer to transaction-safe function if the function call operator is transaction-safe.

Add at the end of 5.2.2 [expr.call] paragraph 1:

... [ Note: ... ] A call to a virtual function that is evaluated within a synchronized (6.x [stmt.sync]) or atomic block (6.x [stmt.tx]) results in undefined behavior if the virtual function is declared transaction_safe noinherit but the final overrider is not declared transaction_safe.

Add after 5.2.2 [expr.call] paragraph 9:

Recursive calls are permitted, except to the function named main (3.6.1)

Calling a function that is not transaction-safe (8.4.4 [dcl.fct.def.tx]) through a pointer to or lvalue of type "transaction-safe function" has undefined behavior.

Drafting note: This restriction might not be required if there is no defined way of obtaining a pointer to transaction-safe function from a pointer to (non-transaction-safe) function. One such way is precluded by the next change.

Change in 5.2.9 [expr.static.cast] paragraph 7:

The inverse of any standard conversion sequence (Clause 4 [conv]) not containing an lvalue-to-rvalue (4.1 [conv.lval]), array-to-pointer (4.2 [conv.array]), function-to-pointer (4.3), null pointer (4.10), null member pointer (4.11), or boolean (4.12), or transaction-safety (4.14 [conv.tx]) conversion, can be performed explicitly using static_cast. ...

Change in 5.10 [expr.eq] paragraph 2:

If at least one of the operands is a pointer, pointer conversions (4.10 [conv.ptr]), transaction-safety conversions (4.14 [conv.tx]), and qualification conversions (4.4 [conv.qual]) are performed on both operands to bring them to their composite pointer type (clause 5 [expr]). Comparing pointers is defined as follows: Before transaction-safety conversions, if one pointer is of type "pointer to function", the other is of type "pointer to transaction_safe function", and both point to the same function, it is unspecified whether the pointers compare equal. Otherwise, ~~Two~~ two pointers compare equal if they are both null, both point to the same function, or both represent the same address (3.9.2), otherwise they compare unequal.

Change in 5.16 [expr.con] paragraph 6:

One or both of the second and third operands have pointer type; pointer conversions (4.10 [conv.ptr]), transaction-safety conversions (4.14 [conv.tx]), and qualification conversions (4.4 [conv.qual]) are performed to bring them to their composite pointer type (5 [expr]). ...

...

Clause 6 [stmt.stmt] Statements

In 6 [stmt.stmt] paragraph 1, add two productions to the grammar:


statement:
      labeled-statement
      attribute-specifier-seq_opt expression-statement
      attribute-specifier-seq_opt compound-statement
      attribute-specifier-seq_opt selection-statement
      attribute-specifier-seq_opt iteration-statement
      attribute-specifier-seq_opt jump-statement
      declaration-statement
      attribute-specifier-seq_opt try-block
      synchronized-statement
      atomic-statement

Add a new paragraph 3 at the end of 6.6 [stmt.jump]:

Transfer out of an atomic block other than via an exception executes the end of the atomic block. [ Note: Colloquially, this is known as committing the transaction. For exceptions, see 15.2 [except.ctor]. -- end note ]

Add a new section 6.x [stmt.sync]:

6.x [stmt.sync] Synchronized statement
synchronized-statement:
       synchronized compound-statement
A synchronized statement is also called a synchronized block.

The start of the synchronized block is immediately before the opening { of the compound-statement. The end of the synchronized block is immediately after the closing } of the compound-statement.

A goto or switch statement shall not be used to transfer control into a synchronized block.

[ Example:
int i = 0;
int f()
{
  synchronized {
    printf("before %d\n", i);
    ++i;
    printf("after %d\n", i);
    return i;
  }
}
Each invocation of f (even when called from several threads simultaneously) retrieves a unique value (ignoring overflow). The output is guaranteed to comprise consistent before/after pairs. -- end example ]

Add a new section 6.x [stmt.tx]:

6.x [stmt.tx] Atomic statement
atomic-statement:
       atomic_noexcept compound-statement
       atomic_cancel compound-statement
       atomic_commit compound-statement
An atomic statement is also called an atomic block. The program is ill-formed if the compound-statement is a transaction-unsafe statement (8.4.4 [dcl.fct.def.tx]).

The start of the atomic block is immediately before the opening { of the compound-statement. The end of the atomic block is immediately after the closing } of the compound-statement. [ Note: Thus, variables with automatic storage duration declared in the compound-statement are destroyed prior to reaching the end of the atomic block; see 6.6 [stmt.jump]. -- end note ]

A goto or switch statement shall not be used to transfer control into an atomic block.

[ Example:
int i = 0;
int f()
{
  atomic_noexcept {
    ++i;
    return i;
  }
}
Each invocation of f (even when called from several threads simultaneously) retrieves a unique value (ignoring overflow). -- end example ]

Section 7 [dcl.dcl] Declarations

Change in 7.4 [dcl.asm] paragraph 1:

... The asm declaration is conditionally-supported; its meaning is implementation-defined. [ Note: Typically it is used to pass information through the implementation to an assembler. -- end note ] It is implementation-defined which asm declarations are transaction-safe, if any.

Add a new section 7.6.6 [dcl.attr.sync]:

7.6.6 [dcl.attr.sync] Attribute for optimization in synchronized blocks
The attribute-token optimize_for_synchronized specifies that a function definition should be optimized for invocation from a synchronized-statement (6.x [stmt.sync]). It shall appear at most once in each attribute-list and no attribute-argument-clause shall be present. The attribute may be applied to the declarator-id in a function declaration. The first declaration of a function shall specify the optimize_for_synchronized attribute if any declaration of that function specifies the optimize_for_synchronized attribute. If a function is declared with the optimize_for_synchronized attribute in one translation unit and the same function is declared without the optimize_for_synchronized attribute in another translation unit, the program is ill-formed; no diagnostic required.
[ Example:
// translation unit 1
[[optimize_for_synchronized]] int f(int);

void g(int x) {
  synchronized {
    ret = f(x*x);
  }
}

// translation unit 2
extern int verbose;

[[optimize_for_synchronized]] int f(int x)
{
  if (x >= 0)
    return x;
  if (verbose > 1)
    std::cerr << "failure: negative x" << std::endl;
  return -1;
}
If the attribute were not present for f, which is not declared transaction_safe, a program might have to drop out of speculative execution in g's synchronized block every time when calling f, although that is only actually required for displaying the error message in the rare verbose error case. -- end example ]

Section 8 [dcl.decl] Declarators

Change in clause 8 paragraph 4:

parameters-and-qualifiers:
     ( parameter-declaration-clause ) cv-qualifier-seq_opt
            ref-qualifier_opt tx-qualifier_opt exception-specification_opt attribute-specifier-seq_opt

tx-qualifier:
     transaction_safe noinherit_opt

Change in 8.3.5 [dcl.fct] paragraphs 1 and 2:

In a declaration T D where D has the form
    D1 ( parameter-declaration-clause ) cv-qualifier-seq_opt
         ref-qualifier_opt tx-qualifier_opt exception-specification_opt attribute-specifier-seq_opt
and the type of the contained declarator-id in the declaration T D1 is "derived-declarator-type-list T", the type of the declarator-id in D is "derived-declarator-type-list transaction_safe_opt function of (parameter-declaration-clause) cv-qualifier-seq_opt ref-qualifier_opt returning T". The optional attribute-specifier-seq appertains to the function type.
In a declaration T D where D has the form
    D1 ( parameter-declaration-clause ) cv-qualifier-seq_opt
         ref-qualifier_opt tx-qualifier_opt exception-specification_opt attribute-specifier-seq_opt trailing-return-type
and the type of the contained declarator-id in the declaration T D1 is "derived-declarator-type-list T", T shall be the single type-specifier auto. The type of the declarator-id in D is "derived-declarator-type-list transaction_safe_opt function of (parameter-declaration-clause) cv-qualifier-seq_opt ref-qualifier_opt returning trailing-return-type". The optional attribute-specifier-seq appertains to the function type.

Change in 8.3.5 [dcl.fct] paragraph 5:

... After determining the type of each parameter, any parameter of type "array of T" or "transaction_safe_opt function returning T" is adjusted to be "pointer to T" or "pointer to transaction_safe_opt function returning T," respectively. ...

Change in 8.3.5 [dcl.fct] paragraph 6:

... The return type, the parameter-type-list, the ref-qualifier, ~~and~~ the cv-qualifier-seq, and the transaction_safe qualifier, but not the default arguments (8.3.6 [dcl.fct.default]) or the exception specification (15.4 [except.spec]), are part of the function type. ...

Add at the end of section 8.3.5 [dcl.fct]:

The transaction_safe noinherit qualifier may only appear in a function declarator that declares a virtual function in a class definition. A virtual function declared with the transaction_safe noinherit qualifier is considered to be declared transaction_safe. [ Note: A virtual function so declared can be overridden by a function that is not transaction-safe (see 10.3 class virtual), but calling such an overrider from a synchronized or atomic block causes undefined behavior (see 5.2.2 expr.call). -- end note ] The first declaration of a function shall be explicitly declared transaction_safe if any declaration of that function is declared transaction_safe; no diagnostic is required if conflicting declarations appear in different translation units. If a redeclaration omits transaction_safe, it is implied if the first declaration was transaction_safe.

Change in section 8.4.1 [dcl.fct.def.general] paragraph 2:

The declarator in a function-definition shall have the form

         D1 ( parameter-declaration-clause ) cv-qualifier-seq_opt
               ref-qualifier_opt exception-specification_opt attribute-specifier-seq_opt 
               parameters-and-qualifiers trailing-return-type_opt

[ Drafting note: This is intended to reduce the grammar redundancies around function declarators. ]

Add a section after 8.4.3 [dcl.fct.def.delete]:

8.4.4 [dcl.fct.def.tx] Transaction-safe function definitions

An expression is transaction-unsafe if it contains any of the following as a potentially-evaluated subexpression (3.2 [basic.def.odr]):

an lvalue-to-rvalue conversion (4.1 [conv.lval]) applied to a volatile glvalue [ Note: referring to a volatile object through a non-volatile glvalue has undefined behavior; see 7.1.6.1 [dcl.type.cv] -- end note ],

an expression that modifies an object through a volatile glvalue,

creation of a temporary object of volatile-qualified type or with a subobject of volatile-qualified type,

a function call (5.2.2 expr.call) whose postfix-expression is an id-expression that names a non-virtual function that is not transaction-safe,

an implicit call of a non-virtual function that is not transaction-safe, or

any other call of a function, where the function type is not "transaction_safe function".

A statement is a transaction-unsafe statement if one of its lexically directly contained elements (including evaluations of default argument expressions in function calls, but ignoring the declaration of default argument expressions, local classes, and the compound-statement of a lambda-expression) is one of the following:

a full-expression that is transaction-unsafe,

an asm-definition (7.4 [dcl.asm]) that is not transaction-safe,

a declaration of a variable of volatile-qualified type or with a subobject of volatile-qualified type, or

a statement that is transaction-unsafe (recursively).

[ Drafting note: This wording is intended to recurse through the "statement" grammar, but not inside expressions. In particular, the compound-statement of a lambda determines the transaction-safety of the lambda's operator() function, but, unless called, does not influence the transaction-safety of the surrounding context. ]

A function has a transaction-safe definition if none of the following applies:

any parameter has volatile-qualified type or has a subobject of volatile-qualified type,

its compound-statement (including the one in the function-try-block, if any) is a transaction-unsafe statement,

for a constructor or destructor, the corresponding class has a volatile non-static data member, or

for a constructor, a full-expression in a mem-initializer or an assignment-expression in a brace-or-equal-initializer that is not ignored (12.6.2 [class.base.init]) is transaction-unsafe.

[ Example:
  extern volatile int * p = 0;
  struct S {
    virtual ~S();
  };

  int f() transaction_safe {
    int x = 0;   // ok: not volatile
    p = &x;      // ok: the pointer is not volatile
    i = *p;      // error: read through volatile glvalue
    S s;         // error: invocation of unsafe destructor
  }
-- end example ]
A function declared transaction_safe shall have a transaction-safe definition.

A function is transaction-safe if it is declared transaction_safe (see 8.3.5 [dcl.fct]) or if it is a non-virtual function defined before its first odr-use (3.2 [basic.def.odr]) and it has a transaction-safe function definition. A specialization of a function template or of a member function of a class template, where the function or function template is not declared transaction_safe, but defined before the first point of instantiation, is transaction-safe if and only if it satisfies the conditions for a transaction-safe function definition. [ Note: Even if a function is implicitly transaction-safe, its function type is not changed to "transaction_safe function". -- end note ]

While determining whether a function f is transaction-safe, f is assumed to be transaction-safe for directly and indirectly recursive calls. [ Example:
  int f(int x) {    // is transaction-safe
    if (x <= 0)
      return 0;
    return x + f(x-1);
  }
-- end example ]

Drafting note: Implicitly-defined special member functions and lambda expressions should be automatically covered by the wording above.

Section 10.3 [class.virtual] Virtual functions

Add a new paragraph at the end of section 10.3 [class.virtual]:

A function that overrides a function declared transaction_safe, but not transaction_safe noinherit, is implicitly considered to be declared transaction_safe. [ Note: Its definition is ill-formed unless it actually has a transaction-safe definition (8.4.4 dcl.fct.def.tx). -- end note ] A function declared transaction_safe noinherit that overrides a function declared transaction_safe (but not transaction_safe noinherit) is ill-formed. [ Example:
struct B {
  virtual void f() transaction_safe;
  virtual ~B() transaction_safe noinherit;
};

// pre-existing code
struct D1 : B
{
  void f() override { }   // ok
  ~D1() override { }   // ok
};

struct D2 : B
{
  void f() override { std::cout << "D2::f" << std::endl; }
       // error: transaction-safe f has transaction-unsafe definition
  ~D2() override { std::cout << "~D2" << std::endl; }     // ok
};

struct D3 : B
{
  void f() transaction_safe noinherit override;
         // error: B::f() is transaction_safe
};

int main()
{
  D2 * d2 = new D2;
  B * b2 = d2;
  atomic_commit {
    B b;        // ok
    D1 d1;      // ok
    B& b1 = d1;
    D2 x;       // error: destructor of D2 is not transaction-safe
    b1.f();     // ok, calls D1::f()
    delete b2;  // undefined behavior: calls unsafe destructor of D2
  }
}
-- end example ]

Clause 13 [over] Overloading

Change in 13.1 [over.load] paragraph 2:

Certain function declarations cannot be overloaded:

Function declarations that differ only in the return type cannot be overloaded.

Function declarations that differ only in the presence or absence of tx-qualifier cannot be overloaded.

...

In 13.3.3.1.1 [over.ics.scs], add an entry to table 12:

Conversion: Transaction-safety conversion

Category: Lvalue transformation

Rank: Exact Match

Subclause: 4.14 [conv.tx]

Change in 13.4 [over.over] paragraph 1:

... ~~The function selected is the one whose type is identical to the function type of the target type required in the context.~~ A function with type F is selected for the function type FT of the target type required in the context if F (after possibly applying the transaction-safety conversion (4.14 [conv.tx])) is identical to FT. [ Note: ... ]

Change in 13.4 [over.over] paragraph 7:

[ Note: ~~There are no standard conversions (Clause 4) of one pointer-to-function type into another. In particular, even~~ Even if B is a public base of D, we have
D* f();
B* (*p1)() = &f;     // error
void g(D*);
void (*p2)(B*) = &g; // error
]

Clause 14 [temp] Templates

Change in 14.1 temp.param paragraph 8:

A non-type template-parameter of type "array of T" or "transaction_safe_opt function returning T" is adjusted to be of type "pointer to T" or "pointer to transaction_safe_opt function returning T", respectively. [ Example: ... ]

Add a new paragraph at the end of 14.8 [temp.fct.spec]:

A specialization instantiated from a function template or from a member function of a class template, where the function template or member function is declared transaction_safe, shall have a transaction-safe definition (8.4.4 [dcl.fct.def.tx]).

Change in 14.8.2.1 temp.deduct.call paragraph 4:

... However, there are three cases that allow a difference:

...

The transformed A can be another pointer or pointer to member type that can be converted to the deduced A via a qualification conversion (4.4 c[onv.qual]) or a transaction-safety conversion (4.14 [conv.tx]).

...

Clause 15 [except] Exception handling

Change in 15.1 except.throw paragraph 3:

... Evaluating a throw-expression with an operand throws an exception; the type of the exception object is determined by removing any top-level cv-qualifiers from the static type of the operand and adjusting the type from "array of T" or "transaction_safe_opt function returning T" to "pointer to T" or "pointer to transaction_safe_opt function returning T," respectively.

Change the section heading of 15.2 [except.ctor] and paragraph 1:

Section 15.2 [except.ctor] Constructors, ~~and~~ destructors, and atomic blocks
As control passes from the point where an exception is thrown to a handler, destructors are invoked for all automatic objects constructed since the try block was entered and still in scope (6.6 [stmt.jump], and atomic blocks are terminated (see below) whose start, but not end, was executed since the try block was entered (6.x [stmt.tx]). The automatic objects are destroyed and atomic blocks are terminated in the reverse order of the completion of their construction and the execution of the start of the atomic blocks.

In section 15.2 [except.ctor], add new paragraphs 4 and 5:

An atomic block is terminated according to its kind. Terminating an atomic_commit block executes the end of the atomic block (1.10 intro.multithread) and has no further effect. [Note: That is, control simply exits the atomic block after causing inter-thread synchronization. -- end note] Terminating an atomic_cancel block, if the type of the current exception does not support transaction cancellation, or terminating an atomic_noexcept block, invokes std::abort (18.5 [support.start.term]). [ Footnote: If the effects of the atomic block become visible to other threads prior to program termination, some thread might make progress based on broken state, making debugging harder. -- end footnote ]. Terminating an atomic_cancel block, if the type of the current exception supports transaction cancellation, cancels the atomic block by performing the following steps, in order:

A temporary object is copy-initialized (8.5 [dcl.init]) from the exception object. [ Note: if the initialization terminates via an exception, std::terminate is called (15.1 [except.throw]). -- end note ]

The values of all memory locations in the program that were modified by side effects of the operations of the atomic block except those occupied by the temporary object are restored to the values they had at the time the start of the atomic block was executed.

The end of the atomic block is executed. [ Note: This causes inter-thread synchronization. -- end note ]

The temporary object is used as the exception object in the subsequent stack unwinding.

[ Note: A cancelled atomic block, although having no visible effect, still participates in data races (1.10 [intro.multithread]). -- end note ]
Non-volatile scalar types support transaction cancellation, as do those types specified as doing so in clauses 18 and 19.

Change in 15.3 except.handle paragraph 3:

A handler is a match for an exception object of type E if

...

the handler is of type cv T or const T& where T is a pointer type and E is a pointer type that can be converted to T by ~~either or both of~~ one or a combination of

a standard pointer conversion (4.10 [conv.ptr]) not involving conversions to pointers to private or protected or ambiguous classes

a qualification conversion (4.4 [conv.qual])

a transaction-safety conversion (4.14 [conv.tx])

...

Change in 15.4 except.spec paragraph 2:

... A type cv T, "array of T", or "transaction_safe_opt function returning T" denoted in an exception-specification is adjusted to type T, "pointer to T", or "pointer to transaction_safe_opt function returning T", respectively.

Standard library

Drafting note: The following guidelines were employed for transaction-safety requirements in the standard library, roughly oriented on the guidelines for constexpr and noexcept:

If a function can unconditionally satisfy its contract without invoking user-defined code, it is declared transaction_safe. Functions declared noexcept strongly hint in that direction. Example: size() member function of containers.
If a function is expected to call potentially user-defined code, that function is specified in prose to be transaction-safe under the condition that all of the potentially invoked user-defined functions are transaction-safe. Example: A copy constructor of a container is only transaction-safe if all required functions of the allocator are transaction-safe and if all required functions for the contained type T are transaction-safe, where "required function" is defined by the respective requirements tables.
There is no code-level specification of conditional transaction-safety. When simply calling such a function, there is no issue, because transaction-safety is inferred from the definition.

Change in 17.5.1.4 [structure.specifications] paragraph 3:

...

Synchronization: the synchronization operations (1.10) applicable to the function

Transactions: the transaction-related properties of the function, in particular whether the function is transaction-safe (8.4.4 [dcl.fct.def.tx])

...

Add a new section in 17.6.5 [conforming]:

17.6.5.16 [lib.txsafe] Transaction safety
This standard explicitly requires that certain standard library functions are transaction-safe (8.4.4 dcl.fct.def.tx). An implementation shall not declare any standard library function signature as transaction_safe except for those where it is explicitly required.

Change in 18.5 [support.start.term] paragraph 4:

[[noreturn]] void abort(void) transaction_safe noexcept ;
The function abort() has additional behavior in this International Standard:

The program is terminated without executing destructors for objects of automatic, thread, or static storage duration and without calling functions passed to atexit() (3.6.3).

Add to 18.6.1 [new.delete] paragraph 1:

... The library versions of the global allocation and deallocation functions are declared transaction_safe (8.3.5 dcl.fct).

Add a first paragraph to section 18.6.2 [alloc.errors]:

The classes bad_alloc, bad_array_length, and bad_array_new_length support transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

In 18.6.2.1 [bad.alloc] and 18.6.2.2 [new.badlength], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe noinherit to the declaration of each virtual member function.

Change in 18.7.2 [bad.cast]:

The class bad_cast defines the type of objects thrown as exceptions by the implementation to report the execution of an invalid dynamic-cast expression (5.2.7 [expr.dynamic.cast]). The class supports transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

In 18.7.2 [bad.cast], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe noinherit to the declaration of each virtual member function.

Change in 18.7.3 [bad.typeid]:

The class bad_typeid defines the type of objects thrown as exceptions by the implementation to report a null pointer in a typeid expression (5.2.8 [expr.typeid]). The class supports transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

In 18.7.3 [bad.typeid], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe noinherit to the declaration of each virtual member function.

In 18.8.1 [exception] and 18.8.2 [bad.exception], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe noinherit to the declaration of each virtual member function.

Change in 18.8.2 [bad.exception]:

The class bad_exception defines the type of objects thrown as described in ~~(15.5.2 [except.unexpected]).~~ 15.5.2 [except.unexpected]. The class supports transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ]

Change in 18.10 [support.runtime] paragraph 4:

The function signature longjmp(jmp_buf jbuf, int val) has more restricted behavior in this International Standard. A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch and throw would invoke any non-trivial destructors for any automatic objects, or would transfer out of a synchronized block (6.x [stmt.sync]) or atomic block (6.x [stmt.tx]).

Change in 19.2 [std.exceptions] paragraph 3:

... These exceptions are related by inheritance. The exception classes support transaction cancellation (15.2 [except.ctor]). [ Note: Special support from the implementation might be necessary to successfully rethrow such an exception after leaving an atomic_cancel block. -- end note ].

Add the following to the synopsis in 19.2 [std.exceptions] paragraph 3:

  template<class T> class tx_exception;

In 19.2 [std.exceptions], add transaction_safe to the declaration of each non-virtual member function and add transaction_safe noinherit to the declaration of each virtual member function.

Add a new section 19.2.10 [tx.exception]:

Class template tx_exception
  namespace std {
    template<class T>
    class tx_exception : public exception {
    public:
       explicit tx_exception(T value) transaction_safe;
       tx_exception(T value, const char* what_arg) transaction_safe;
       tx_exception(T value, std::string& what_arg) transaction_safe;
       T get() const transaction_safe;      
    };
  }
A specialization of tx_exception supports transaction cancellation (15.2 [except.ctor]) only if T is a trivially-copyable type (3.9 [basic.types]).
tx_exception(T value) transaction_safe;
Effects: Constructs an object of class tx_exception.

Postcondition: get() == value
tx_exception(T value, const char * what_arg) transaction_safe;
Effects: Constructs an object of class tx_exception.

Postcondition: strcmp(what(), what_arg) == 0 && get() == value.
tx_exception(T value, const string& what_arg) transaction_safe;
Effects: Constructs an object of class tx_exception.

Postcondition: strcmp(what(), what_arg.c_str()) == 0 && get() == value.

Change in 20.7.3.2 [pointer.traits.functions]:

static pointer pointer_traits::pointer_to(see below r);
static pointer pointer_traits<T*>::pointer_to(see below r) transaction_safe noexcept;
...
Transactions: The first member function is transaction-safe if the invoked member function of Ptr is transaction-safe.

Change the signature in 20.7.5 [ptr.align] paragraph 1:

void* align(std::size_t alignment, std::size_t size,
    void*& ptr, std::size_t& space) transaction_safe;

In 20.7.8.2 [allocator.traits.members], add before paragraph 1:

A function in this section is transaction-safe if the invoked function (as specified below) is transaction-safe.

In 20.7.9.1 [allocator.members], add "transaction_safe" to the declarations of the following member functions: address (twice), allocate, deallocate, max_size.

Change in 20.7.9.1 [allocator.members] paragraphs 12 and 13:

template <class U, class... Args>
  void construct(U* p, Args&&... args);
Effects: ::new((void *)p) U(std::forward(args)...)
Transactions: Transaction-safe if the invoked constructor of U is transaction-safe.
template <class U>
  void destroy(U* p);
Effects: p->~U()
Transactions: Transaction-safe if the destructor of U is transaction-safe.

Change the signatures in 20.7.11 [temporary.buffer]:

template <class T>
  pair<T*, ptrdiff_t> get_temporary_buffer(ptrdiff_t n) transaction_safe noexcept;

...

template <class T> void return_temporary_buffer(T* p) transaction_safe;

Change in 20.7.12 [specialized.algorithms] paragraph 1:

... In the following algorithms, if an exception is thrown there are no effects. Each of the following functions is transaction-safe if the constructor invoked via the placement allocation function is transaction-safe.

Change the signature in 20.7.12.1 [specialized.addressof]:

template <class T> T* addressof(T& r) transaction_safe noexcept;

Add after 20.7.13 [c.malloc] paragraph 2:

The contents are the same as the Standard C library header <stdlib.h>, with the following changes:

The functions are declared transaction-safe.

[ Drafting note: This covers calloc, malloc, free, and realloc.]

Change in 20.7.13 [c.malloc] paragraph 7:

The contents are the same as the Standard C library header <string.h>, with the change to memchr() specified in 21.8 [c.strings]. The functions are declared transaction-safe.

[ Drafting note: This covers memchr, memcmp, memcpy, memmove, and memset. ]

Change in 20.8.1 [unique.ptr] paragraph 5:

... The template parameter T of unique_ptr may be an incomplete type. Each of the functions in this section is transaction-safe if either no functions are called or all functions called are transaction-safe.

Add after 21.1 [strings.general] paragraph 1:

All functions in this Clause are transaction-safe if the required operations on the supplied allocator (17.6.3.5 [allocator.requirements]) and character traits (21.2.1 [char.traits.require]) are transaction-safe.

In 21.4.3 [string.iterators], 21.4.4 [string.capacity], 21.4.5 [string.access], add "transaction_safe" to the declarations of all member functions.

Add in 23.2.1 [container.requirements.general] after paragraph 6:

... If the container is empty, then begin() == end().
The member functions begin(), end(), cbegin(), cend(), size(), max_size(), and empty() are transaction-safe.

Add in 23.2.1 [container.requirements.general] after paragraph 8:

... In all container types defined in this Clause, the member get_allocator() returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement.
A constructor, destructor, or assignment operator of a container other than array is transaction-safe if all member functions of allocator_traits<allocator_type> and the respective required operations for Compare, Pred, or Hash objects (if any) and for values of type T are transaction-safe. The equality comparisons == and != are transaction-safe if equality comparison of the elements (as required by EqualityComparable) is transaction-safe.

Change in 23.2.1 [container.requirements.general] paragraph 9:

... It is unspecified whether an iterator with value a.end() before the swap will have value b.end() after the swap. The swap functions are transaction-safe if swapping the allocator, Compare, Pred, and Hash objects, if any, are all transaction-safe.

Add in 23.2.1 [container.requirements.general] after paragraph 10:

If the iterator type of a container belongs to the bidirectional or random access iterator categories (24.2 [iterator.requirements]), the container is called reversible and satisfies the additional requirements in Table 97.

[ table ]
The member functions rbegin(), rend(), crbegin(), and crend() are transaction-safe.

Change in 23.2.1 [container.requirements.general] paragraph 13:

Note: the algorithm lexicographical_compare() is defined in Clause 25 [algorithms].
The relational operators are transaction-safe if the required operator< for the element values is transaction-safe.

Add a note in table 99 (allocator-aware container) of 23.2.1 [container.requirements.general] paragraph 15 for get_allocator():

transaction-safe if the copy-constructor of A is transaction-safe

Add in 23.2.3 [sequence.reqmts] after paragraph 13:

The iterator returned by a.erase(q1,q2) points to the element pointed to by q2 prior to any elements being erased. If no such element exists, a.end() is returned.
A member function emplace, insert, erase, clear, or assign is transaction-safe if all member functions of allocator_traits<allocator_type> and the respective required operations for values of type T (if any) are transaction-safe.

Add in 23.2.3 [sequence.reqmts] before paragraph 17:

[ table ]
The member functions front() and back() as well as the indexing operation a[n] are transaction-safe. A member function emplace_front, emplace_back, push_front, push_back, pop_front, pop_back is transaction-safe if all member functions of allocator_traits<allocator_type> and the respective required operations for values of type T (if any) are transaction-safe.
The member function at() provides bounds-checked access to container elements. at() throws out_of_range if n >= a.size().

Add in 23.2.4 [associative.reqmts] before paragraph 13:

A member function emplace, emplace_hint, insert, erase, clear, find, count, lower_bound, upper_bound, and equal_range is transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe, the required operations on the comparison object are transaction-safe, and the respective required operations for values of type T (if any) are transaction-safe. The member functions key_comp() and value_comp() are transaction-safe if copying the comparison object is transaction-safe.
The member function templates find, count, lower_bound, upper_bound, and equal_range shall not participate in overload resolution unless ...

Add in 23.2.5 [unord.req] after paragraph 12:

The behavior of a program that uses operator== or operator!= on unordered containers is undefined unless the Hash and Pred function objects respectively have the same behavior for both containers and the equality comparison operator for Key is a refinement [ Footnote: ... ] of the partition into equivalent-key groups produced by Pred.

A member function emplace, emplace_hint, insert, erase, clear, find, count, equal_range, bucket, rehash, and reserve is transaction-safe if all member functions of allocator_traits<allocator_type>, the required operations on Hash and Pred, and the respective required operations for values of type T (if any) are transaction-safe. The member functions hash_function() and key_eq() are transaction-safe if copying the hash function object or the key equality predicate, respectively, is transaction-safe. The member functions bucket_count, max_bucket_count, bucket_size, begin, end, cbegin, cend, load_factor, and max_load_factor are transaction-safe.

In 23.3.2.1 [array.overview] and the corresponding subsections, add "transaction_safe" to the declarations of all member functions except fill and swap. [ Drafting note: The latter two are transaction-safe if they have a transaction-safe definition as specified by their "effects" clause. ]

Change in 23.3.2.2 [array.cons]:

... In addition to the requirements specified in the container requirements table, the implicit move constructor and move assignment operator for array require that T be MoveConstructible or MoveAssignable, respectively. Such an implicitly-declared special member function is transaction-safe if its implicit definition is a transaction-safe function definition (8.4.4 [dcl.fct.def.tx]).

In 23.3.3.1 [deque.overview], add "transaction-safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], front, back.

Add in 23.3.3.3 [deque.capacity] for both resize functions:

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> and the required operations for values of type T are transaction-safe.

Add in 23.3.3.3 [deque.capacity] after paragraph 7 (shrink_to_fit):

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe.

In 23.3.4.1 [forwardlist.overview] and 23.3.4.6 [forwardlist.ops], add "transaction-safe" to the declarations of all variants of the begin and end member functions and to the declarations of max_size, empty, front, splice_after, and reverse.

Change 23.3.4.5 [forwardlist.modifiers] paragraph 1:

... Erasing n elements from a forward_list is linear in n and the number of calls to the destructor of type T is exactly equal to n. A function specified in this section is transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe and the respective required operations for values of type T (if any) are transaction-safe.

Add in 23.3.4.6 [forwardlist.ops] paragraph 15 (for remove):

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe and the equality comparison or predicate call is transaction-safe.

Add in 23.3.4.6 [forwardlist.ops] paragraph 18 (for unique):

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe and the equality comparison or predicate call is transaction-safe.

Add in 23.3.4.6 [forwardlist.ops] paragraph 22 (for merge):

Transactions: Transaction-safe if the comparison is transaction-safe.

Add in 23.3.4.6 [forwardlist.ops] paragraph 26 (for sort):

Transactions: Transaction-safe if the comparison is transaction-safe.

In 23.3.5.1 [list.overview] and 23.3.5.5 [list.ops], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, front, back, splice, and reverse.

Add in 23.3.5.3 [list.capacity] for both resize functions:

Transactions: Transaction-safe if all member functions of allocator_traits and the required operations for values of type T are transaction-safe.

Add in 23.3.5.5 [list.ops] after paragraph 18 (for remove):

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe and the equality comparison or predicate call is transaction-safe.

Add in 23.3.5.5 [list.ops] after paragraph 21 (for unique):

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe and the equality comparison or predicate call is transaction-safe.

Add in 23.3.5.5 [list.ops] after paragraph 25 (for merge):

Transactions: Transaction-safe if the comparison is transaction-safe.

Add in 23.3.5.5 [list.ops] after paragraph 31 (for sort):

Transactions: Transaction-safe if the comparison is transaction-safe.

In 23.3.6.1 [vector.overview], 23.3.6.3 [vector.capacity], and 23.3.6.4 [vector.data], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, capacity, empty, operator[], front, back, data.

Add in 23.3.6.3 [vector.capacity] after paragraph 6 (for reserve):

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> and the required operations for values of type T are transaction-safe.

Add in 23.3.6.3 [vector.capacity] after paragraph 9 (for shrink_to_fit):

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> are transaction-safe.

Add in 23.3.6.3 [vector.capacity] for both resize functions:

Transactions: Transaction-safe if all member functions of allocator_traits<allocator_type> and the required operations for values of type T are transaction-safe.

In 23.3.7 [vector.bool], add "transaction_safe" to the declarations of all variants of the begin and end member functions, to the declarations of size, max_size, capacity, empty, operator[], front, back, and flip, and to the static member function swap.

In 23.4.4.1 [map.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.4.5.1 [multimap.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.4.6.1 [set.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.4.7.1 [multiset.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, and empty.

In 23.5.4.1 [unord.map.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

In 23.5.5.1 [unord.multimap.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

In 23.5.6.1 [unord.set.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

In 23.5.7.1 [unord.multiset.overview], add "transaction_safe" to the declarations of all variants of the begin and end member functions and to the declarations of size, max_size, empty, operator[], bucket_count, max_bucket_count, bucket_size, load_factor, and max_load_factor.

Add in 23.6.1 [container.adaptors.general] after paragraph 3:

For container adaptors, no swap function throws an exception unless that exception is thrown by the swap of the adaptor's Container or Compare object (if any).
A member function f of a container adaptor is transaction-safe if the required member functions of the adaptor's Container and Compare (if any) are transaction-safe, as given by the specification for f.

Change in 24.4.4 [iterator.operations] paragraph 1:

Since only random access iterators provide + and - operators, the library provides two function templates advance and distance. These function templates use + and - for random access iterators (and are, therefore, constant time for them); for input, forward and bidirectional iterators they use ++ to provide linear time implementations. A specialization of a function template specified in this Clause is transaction-safe if all functions invoked for operations required for the template arguments are transaction-safe.

Change in 24.5.1 [reverse.iterators] paragraph 1:

Class template reverse_iterator is an iterator adaptor that iterates from the end of the sequence defined by its underlying iterator to the beginning of that sequence. The fundamental relation between a reverse iterator and its corresponding iterator i is established by the identity: &*(reverse_iterator(i)) == &*(i - 1). A member function specified in this Clause is transaction-safe if all functions invoked for operations required for the template argument of reverse_iterator are transaction-safe.

Add a new paragraph after 24.5.2 [insert.iterators] paragraph 2:

A function or function template specified in this Clause is transaction-safe if all functions invoked for operations required for the template arguments are transaction-safe.

Add a new paragraph after 24.5.3 [move.iterators] paragraph 2:

A member function specified in this Clause is transaction-safe if all functions invoked for operations required for the template arguments are transaction-safe.

Change in 24.7 [iterator.range] paragraph 1:

In addition to being available ..., and <vector>. A specialization of a function template specified in this Clause is transaction-safe if the expression specified in the Returns statement is not transaction-unsafe (8.4.4 [dcl.fct.def.txt]).

In 24.7 [iterator.range], add "transaction_safe" to the declarations of begin(T (&array)[N]) and end(T (&array)[N]).

Add a new 25.1 [algorithms.general] paragraph 13:

A specialization of a function template specified in this Clause is transaction-safe if all functions invoked for operations required for the template arguments are transaction-safe. [ Note: If no functions are invoked (for example, if only built-in types are involved), the specialization is transaction-safe. -- end note ] [ Example: The fill function (25.3.6 alg.fill) is transaction-safe if all required operations of its ForwardIterator template argument are transaction-safe and if T's copy-assignment operator is transaction-safe. -- end example ]

Add after 26.8 [c.math] paragraph 4:

The contents of these headers are the same as the Standard C library headers <math.h> and <stdlib.h> respectively, with the following changes:
The functions from <stdlib.h> except rand and srand are declared transaction-safe.

[ Drafting note: This covers abs, ldiv, ~~rand~~, div, llabs, ~~srand~~, labs, and lldiv.]