Barrier statement optional expression type is an integer type, not just 'int'

[Former user]

Originally reported on Google Code with ID 64

Version 1.2 of the UPC specification at 6.6.1p2 (Constraint) describes the type of the
optional expression of a barrier/notify/wait statement as follows:

"expression shall have type int."

This issue proposes that the constraint should be amended to:

"expression shall have integer type."

Consider the following:

  upc_barrier 1;

Here, the optional expression value (1) is an integer type, but not strictly speaking
an 'int' type.

Further, the range of 'int' is implementation-defined.

Should the specification state the allowed range of values for barrier statement expressions?
See related issue #26.

If the specification is changed to specify "integer type", then it would be useful/necessary
to describe the allowed implementation-defined range (See issue #21, which proposes
that suggested allowed ranges of values be documented in a separate annex.)

Reported by gary.funck on 2012-07-17 19:07:21

[Former user]

``` Set default Consensus to "Low". ```

Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

[Former user]

``` Change Status to New: Requires review. ```

Reported by `gary.funck` on 2012-08-19 23:37:41 - Status changed: `New`

[Former user]

``` I don't really see a problem with the expression being an 'int' type whose range is implementation-defined: regardless of how we specify the type, I think we want the range of values to be implementation-defined.

It seems like the only ambiguity here is that upc_barrier/upc_notify/upc_wait are keywords instead of function calls, so although we state the argument is of type int, the C rules for function argument conversion do not automatically apply. For reference, here is the C99 text for function argument conversion from 6.5.2.2:

---------------------------------------------- Constraint: Each argument shall have a type such that its value may be assigned to an object with the unqualified version of the type of its corresponding parameter ... Semantics: If the expression that denotes the called function has a type that does include a prototype, the arguments are implicitly converted, as if by assignment, to the types of the corresponding parameters, taking the type of each parameter to be the unqualified version of its declared type. The ellipsis notation in a function prototype declarator causes argument type conversion to stop after the last declared parameter. The default argument promotions are performed on trailing arguments. ----------------------------------------------

Specifying a constraint of "integer type" or even "integral type" is too loose, because it would allow (long) or (long long) arguments, which we do not wish to allow. Keep in mind that we currently specify the initial/final barriers as follows:

------------------------------------------- The barrier operations at thread startup and termination have a value of {\em expression} which is not in the range of the type {\tt int}.\footnote{These barriers are never expressed in a UPC source program and this semantic says these barrier values can never match one expressed in a user program.} -------------------------------------------

We could of course also amend that statement, but that doesn't seem necessary to solve this ambiguity.

Proposal: --------- Change constraint 6.6.1-2: "expression shall have type int."

to instead read: "expression shall have a type such that its value may be assigned to an object of type int." ```

Reported by `danbonachea` on 2012-09-18 17:07:20

[Former user]

``` Change announcement mailed 9/18/2012

Proposed Change: ------------------------- --- upc-language.tex (revision 119) +++ upc-language.tex (working copy) @@ -788,7 +790,9 @@

{\bf Constraints}

-\np{\em expression} shall have type {\tt int}. +\np{\em expression} shall have +\xadded[id=DB]{64}{a type such that its value may be assigned to an object of} +type {\tt int}.

{\bf Semantics}

```

Reported by `danbonachea` on 2012-09-19 04:37:02 - Status changed: `PendingApproval` - Labels added: Consensus-Medium - Labels removed: Consensus-Low

[Former user]

``` I concur with this proposed improvement in wording. It handles the situations that I had observed that appeared to be problematic.

I think there might be a test case out there that does something like this: upc_barrier 1.0; which currently is diagnosed as an error, because 1.0 is not an 'int' constant. After application of the new wording, this would be valid. That is presumably acceptable and desirable?

Similarly, upc_barrier NULL; where NULL is ((void *)0) will be valid as well.

```

Reported by `gary.funck` on 2012-09-19 05:02:07

[Former user]

``` Here are the C99 constraints for assignment (6.5.16.1): --------------------------------- — the left operand has qualified or unqualified arithmetic type and the right has arithmetic type; — the left operand has a qualified or unqualified version of a structure or union type compatible with the type of the right; — both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; — one operand is a pointer to an object or incomplete type and the other is a pointer to a qualified or unqualified version of void, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; — the left operand is a pointer and the right is a null pointer constant; or — the left operand has type _Bool and the right is a pointer. ---------------------------------

With the proposed change, upc_barrier 1.0 would not be a constraint violation, as it satisfies case 1 above.

However, upc_barrier ((void*)0) WOULD be a constraint violation (with a required diagnostic), because pointers cannot be directly assigned to an object of type int by the C99 rules for assignment.

Your example makes me ponder this case: upc_barrier 1.5; Is it clear from context that the implementation will round this to 1 and use that as the barrier value? Or should we add something in semantics to be more explicit? If so, that should probably just be folded into the same semantic paragraph that defines a range of allowed barrier values for issue 26 (let's keep this issue specific to the constraint clause).

```

Reported by `danbonachea` on 2012-09-19 05:59:08

[Former user]

``` Consider the text shown below from C99 for conversion of the optional arg to "return". The key phase, in my mind, is "the value is converted as if by assignment". That makes the "1.5" case unambiguous.

So, I propose:

Change constraint 6.6.1-2: "expression shall have type int."

to instead read: "expression shall have type int, or else shall be converted as if by assignment to an object of type int."

6.8.6.4 The return statement Constraints [...] 3 If a return statement with an expression is executed, the value of the expression is returned to the caller as the value of the function call expression. If the expression has a type different from the return type of the function in which it appears, the value is converted as if by assignment to an object having the return type of the function. ```

Reported by `[e-mail]` on 2012-09-19 06:23:03

[Former user]

``` "shall be converted as if by assignment"

I agree this is probably the correct wording to clarify the conversion, but such wording does NOT belong in a Constraint, which is the topic of this issue. The paragraph you quoted from C99 6.8.6.4 actually appears under Semantics, not Constraints. This issue focuses on the type-checking rules for the argument, not the semantics of it.

As I mentioned in comment #6, I think this second ambiguity should be resolved with a paragraph under Semantics, and it should probably be the same paragraph that resolves closely-related issue 26.

```

Reported by `danbonachea` on 2012-09-19 21:36:06

[Former user]

``` I concede the point Dan makes in the previous comment: The conversion should be described in Semantics, not in Constraints.

I withdraw my proposed (in comment #7) replacement text. ```

Reported by `[e-mail]` on 2012-09-19 22:15:37

[Former user]

This PendingApproval issue was ratified at the 10/19/2012 telecon, and merged into the
working draft in SVN 175.

Reported by danbonachea on 2012-10-22 18:43:14 - Status changed: Ratified