Clarification: cast of (shared <type> * shared) is an error

[GoogleCodeExporter]

Cast of (shared <type> * shared) is an error according to one reading of
the specification, but the specification language could be improved to
definitively state this rule.

The second 'shared' applies to the actual pointer value itself, not the pointer 
component type.

In version 1.2 of the UPC specification 6.4.3p1 (constraints) states:

A shared type qualifier shall not appear in a type cast where the corresponding 
pointer component of the type of the expression being cast is not 
shared-qualified.[9] An exception is made when the constant expression 0 is 
cast, the result is called the null pointer-to-shared.[10]

The implication here is that 'shared' can only be used in a cast as a qualifier 
to the component type of a pointer-to-shared type.

This dis-allows:

shared int x = 1;
shared int y = 2;
shared int * shared p;

int main(void)
{
  if (MYTHREAD == 0)
    {
       x = (shared int) y;  // Error
       p = (shared int * shared)&x; // Error
    }
  return 0;
}

GUPC issues the following errors:

shared-cast.upc:9:8: error: UPC does not allow casts to a shared type
        x = (shared int) y;  // Error
        ^
shared-cast.upc:10:8: error: UPC does not allow casts to a shared type
        p = (shared int * shared)&x; // Error
        ^

Some vendor compilers may currently accept either or both casts without 
complaint.

Original issue reported on code.google.com by gary.funck on 18 Jul 2012 at 12:01

[GoogleCodeExporter]

This is just a more complicated version of issue 75, and I believe the same 
argument applies.

Top-level type qualifiers on values are always completely meaningless, and the 
top-level shared qualifiers in the cast of both x and y are meaningless. If you 
replace the top-level "shared" qualifier with "const", it remains equally 
meaningless (but harmless and permitted). The quoted language from the UPC spec 
was intended to constrain the appearance of shared qualifiers as NON top-level 
qualifiers in type casts.

Now granted, a user who has written this meaningless type qualifier in his cast 
is probably confused, and a warning might be justified to inform him of his 
confusion. But as it is harmless, I see no reason to prohibit it.

Original comment by danbonachea on 3 Aug 2012 at 2:20

[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]

Take ownership from Gary.  I will summarize this issue in the next telecon.

Original comment by yzh...@lbl.gov on 17 Sep 2012 at 9:17

[GoogleCodeExporter]

Summary: I agree with Dan in Comment 1 that this is essentially the same issue 
as Issue 75.  And we should treat this issue consistently with Issue 75.

My recommendation is to close this issue without changes.

Original comment by yzh...@lbl.gov on 20 Sep 2012 at 6:30

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

As I noted in Issue 75:

By leaving as "no change", this means that there is nothing in spec, except by 
inheritance of the C99 spec, and then by extension of C99's handling of 
qualfiiers that we can arrive at the conclusion that this sort of cast is 
allowed.

I'd like to see something more helpful here: something in "Semantics" or 
something in an example, for example.

Original comment by gary.funck on 20 Sep 2012 at 8:10

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

"this means that there is nothing in spec, except by inheritance of the C99 
spec"

This inheritance is the general form of the UPC spec, so I don't really see 
specification-by-inheritance as a problem. C99 6.5.4 states:

"A cast does not yield an lvalue. Thus, a cast to a qualified type has the same 
effect as a cast to the unqualified version of the type."

which already seems very clear and directly applicable to UPC. Thus the cast 
(shared int) "has the same effect" as the cast (int) and there is no error. In 
this case, shared really is "just another type qualifier" and inherits the C99 
rule for qualifiers in casts. I don't see the value of re-stating the C99 rule, 
perhaps we can just add this to the rationale doc?

Original comment by danbonachea on 20 Sep 2012 at 9:48

[GoogleCodeExporter]

In principle, I support the minimalist approach of placing no more in the UPC 
spec. than is needed, and certainly by a reasonable interpretation the current 
specification does that with respect to the cited use case.

I will simply repeat my request:

"I'd like to see something more helpful here: something in "Semantics" or 
something in an example ...".

Although "shared" is defined as a qualifier, it has some unique properties that 
in some ways resemble storage specifiers (like "auto" and "static") because 
"shared" in a variable declaration designates a "scope" that spans UPC threads. 
 I am probably not saying this in the most succinct and technically accurate 
way.  In any event, because "shared" has some unique properties that are 
distinct for UPC, I personally would like to see areas like this clarified in 
the specification.

Certainly the position has been taken on other similar issues that 
clarifications like this should be relegated to a UPC Rationale document.  
Perhaps if I knew that the Rationale document were to be released with the 
version 1.3 UPC language specification document I would view that approach as 
sufficient.  Probably, though, I would still prefer that the spec. is clearer 
and more explicit in defining that gratuitous casts to shared like those in 
this issue and Issue 75 are valid and allowed.

Original comment by gary.funck on 21 Sep 2012 at 3:57

[GoogleCodeExporter]

In the last telecon, the attendees agreed that this was essentially the same 
issue as Issue 75, as explained in Comment 1.  We will handle this issue the 
same as Issue 75.

For reference, the resolution for Issue 75 is
"No change to the UPC Spec document and Add clarification and examples in the 
Rationale document."     

Original comment by yzh...@lbl.gov on 1 Oct 2012 at 5:07

• Changed state: NoChange