Thomas Plum, tplum@plumhall.com
Clark Nelson, clark.nelson@intel.com
Blaine Garst, blaine@apple.com
Nick Stoughton, nick@usenix.org
November 4 2010

WG14/N1537 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. The phrase "qualified or unqualified type", without explicit mention of "atomic", does not include the atomic types. (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; additionally, 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.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.

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.

Add a new paragraph to 6.7.3:

If other qualifiers appear along with the _Atomic qualifier in a specifier-qualifier-list, the resulting type is the so-qualified atomic type.
EXAMPLE 3 An object declared as
_Atomic volatile int *p; declares that p has the type "pointer to volatile atomic int", a pointer to a volatile-qualified atomic type.

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.4 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 or a function type.

Semantics

The properties associated with atomic types are meaningful only for expressions that are lvalues. If the _Atomic keyword is immediately followed by a left parenthesis, it is interpreted as an type specifier (with a type name), not as a type qualifier.

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