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

[GoogleCodeExporter]

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

Original issue reported on code.google.com by gary.funck on 17 Jul 2012 at 7:07

[GoogleCodeExporter]

Set default Consensus to "Low".

Original comment by gary.funck on 19 Aug 2012 at 11:26

• Added labels: Consensus-Low

[GoogleCodeExporter]

Change Status to New: Requires review.

Original comment by gary.funck on 19 Aug 2012 at 11:37

• Changed state: New

[GoogleCodeExporter]

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

Original comment by danbonachea on 18 Sep 2012 at 5:07

[GoogleCodeExporter]

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}

Original comment by danbonachea on 19 Sep 2012 at 4:37

• Changed state: PendingApproval
• Added labels: Consensus-Medium
• Removed labels: Consensus-Low

[GoogleCodeExporter]

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.

Original comment by gary.funck on 19 Sep 2012 at 5:02

[GoogleCodeExporter]

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

Original comment by danbonachea on 19 Sep 2012 at 5:59

[GoogleCodeExporter]

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.

Original comment by phhargr...@lbl.gov on 19 Sep 2012 at 6:23

[GoogleCodeExporter]

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

Original comment by danbonachea on 19 Sep 2012 at 9:36

[GoogleCodeExporter]

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. 

Original comment by phhargr...@lbl.gov on 19 Sep 2012 at 10:15

[GoogleCodeExporter]

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

Original comment by danbonachea on 22 Oct 2012 at 6:43

• Changed state: Ratified