Thomas Plum, [email protected]
November 4 2010
WG14/N1535 Synthesis re _Atomic
We are urged to search for a consensus, and to take into account all expressions of positions. Here is one possible solution:

Changes to 6.2.5 Types:

Add a new bullet to para 20:

Change para 27:

_Atomic qualifier , which may combine with volatile and restrict . The presence of the _Atomic qualifier designates an atomic type. The size, representation, and alignment of an _Atomic-qualified atomic type need not be the same as those of the corresponding unqualified type. Therefore, this Standard explicitly uses the phrase "atomic, qualified, or unqualified type" whenever the atomic version of a type is permitted along with the other qualified versions of a type. (Atomic types are a conditional feature that implementations need not support; see 6.10.8.)

Globally change _Atomic-qualified to atomic.

Change 6.3.2.1 para 2:

... If the lvalue has qualified type, the value has the unqualified version of the type of the lvalue; if the lvalue has atomic type, the value has the non-atomic version of the type of the lvalue; otherwise, the value has the type of the lvalue....

Change 6.5.2.4p1:

The operand of the postfix increment or decrement operator shall have atomic, qualified, or unqualified real or pointer type, and shall be a modifiable lvalue.

Change 6.5.3.1p1:

The operand of the prefix increment or decrement operator shall have atomic, qualified, or unqualified real or pointer type, and shall be a modifiable lvalue.

Change 6.5.4p2:

Unless the type name specifies a void type, the type name shall specify atomic, qualified, or unqualified scalar type, and the operand shall have scalar type.

Change 6.5.16p3:

An assignment operator stores a value in the object designated by the left operand. An assignment expression has the value of the left operand after the assignment,110) but is not an lvalue. The type of an assignment expression is the type of the left operand unless the left operand has qualified type, in which case it is the unqualified version of the type of the left operand the left operand would have after lvalue conversion. The side effect of updating ....

Change 6.5.16.1p1:

One of the following shall hold:111)

Change 6.5.16.2p1:

For the operators += and -= only, either the left operand shall be a an atomic, qualified, or unqualified pointer to a complete object type, and the right shall have integer type, or the left operand shall have atomic, qualified, or unqualified arithmetic type, and the right shall have arithmetic type.

Change 6.5.16.2p2:

For the other operators, the left operand shall have atomic, qualified, or unqualified arithmetic type, and (considering the type the left operand would have after lvalue conversion) each operand shall have arithmetic type consistent with those allowed by the corresponding binary operator.

Change 6.7.3 para 5:

... If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.132) If an attempt is made to refer to an object defined with an _Atomic-qualified type through use of an lvalue with non-_Atomic-qualified type, the behavior is undefined.

Note: This statement was needed only because the aliasing rule otherwise allowed such punning when _Atomic was considered a qualifier. If atomic types are just distinct types, this undefined behavior is implied by the type-based aliasing rule.

There are several changes that go beyond what was intended by N1524; we recommend making these changes, but we present them separately so that the committee can make an informed choice:

Add a new section:

6.7.2.3 Atomic type specifiers

Constraints

The type name in an atomic type specifier shall not refer to an array type, a function type, an atomic type, or a qualified type. The type modified by the _Atomic qualifier shall not be an array type, a function type, an atomic type, or a qualified type.

Semantics

The properties associated with atomic types are meaningful only for expressions that are lvalues.

Note: It may be desirable to move some other statements about atomic types to this section as well.

Change 6.7.6.3p1:

A function declarator shall not specify a return type that is an atomic type,a function type, or an array type.

Change 6.7.6.3p4:

After adjustment, the parameters in a parameter type list in a function declarator that is part of a definition of that function shall not have incomplete type. The type in a parameter declaration shall not be an atomic type.

Change 6.9.1p6:

If the declarator includes an identifier list, each declaration in the declaration list shall have at least one declarator, those declarators shall declare only identifiers from the identifier list, no declaration in the declaration list shall declare an object with atomic type, and every identifier in the identifier list shall be declared. ...

To implement N1524 exactly as intended would require several more changes. Upon consideration, we recommend against these changes, but present them here so that the committee can make an informed choice:

Change 6.5.2.3p1:

The first operand of the . operator shall have an atomic, qualified, or unqualified structure or union type, and the second operand shall name a member of that type.

Change 6.5.2.3p2:

The first operand of the -> operator shall have type ''pointer to atomic, qualified, or unqualified structure'' or ''pointer to atomic, qualified, or unqualified union'', and the second operand shall name a member of the type pointed to.