Clarification: a cast from non-shared to shared is an error

[Former user]

Originally reported on Google Code with ID 75

Consider:

  int i;
  shared int s = (shared int)i; /* cast error */
  shared int *p = (shared int *)&i; /* cast error */

GUPC issues the following errors:

scast.upc:2:1: error: UPC does not allow casts to a shared type
 shared int s = (shared int)i; /* cast error */
 ^
scast.upc:3:1: error: UPC does not allow casts from a local pointer to a pointer-to-shared
 shared int *p = (shared int *)&i; /* cast error */
 ^

The attempted cast to (shared int *) is covered in the spec.
I am unsure re: the straight cast from a local int to (shared int).

Reported by gary.funck on 2012-07-18 00:11:36

[Former user]

``` Gary asks if the following is legal: shared int s = (shared int)i; /* cast error */

I say is is NOT legal, by analogy to other qualifiers in C99. Looking at C99, I'd consider "shared" to be analogous to the storage-class specifiers "static", "auto" or "register":

int main(void) { int i = 411;

/* Expect OK: */ volatile int vi = (volatile int)i; const int ci = (const int)i;

/* Not sure what to expect: */ static int si = (static int)i; register int ri = (register int)i; auto int ai = (auto int)i;

return 0; }

With that example, gcc 4.7.0 and clang-3.1 both agree that "static", "register" and "auto" are invalid in a cast:

$ gcc -std=c99 -pedantic test.c test.c: In function 'main': test.c:9: error: expected expression before 'static' test.c:9: error: expected ',' or ';' before 'i' test.c:10: error: expected expression before 'register' test.c:10: error: expected ',' or ';' before 'i' test.c:11: error: expected expression before 'auto' test.c:11: error: expected ',' or ';' before 'i'

$ $ clang -std=c99 -pedantic test.c test.c:9:22: error: expected expression static int si = (static int)i; ^ test.c:10:22: error: expected expression register int ri = (register int)i; ^ test.c:11:22: error: expected expression auto int ai = (auto int)i; ^ 3 errors generated.

P.S. You all remember the "auto" keyword, right?

```

Reported by `[e-mail]` on 2012-07-18 00:29:37

[Former user]

``` In reaction to Paul's argument, shared is currently defined as a type qualifier, not a storage specifier, so the analogy to the C99 storage-class specifiers isn't really conclusive on its own.

int i; shared int s = (shared int)i;

I don't see any reason to prohibit this cast, because it is meaningless. A top-level type qualifier on a value is meaningless, just as it would be meaningless (but not prohibited) if the cast was (const int) or (volatile int).

Move to close with NoChange.

```

Reported by `danbonachea` on 2012-08-03 13:48:49

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

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

Reported by `[e-mail]` on 2012-09-17 21:16:02

[Former user]

``` Summary: This issue is concerned about whether a cast from non-shared to shared in top-level type qualifiers on a value is an error. For example,

shared int s = (shared int)i;

Paul thinks this is an error and Dan thinks it is meaningless. In either way, no change to the spec document is needed.

My recommendation is to close this issue without changes.

```

Reported by `[e-mail]` on 2012-09-20 18:27:58 - Labels added: Priority-Low - Labels removed: Priority-Medium

[Former user]

``` As an UPC compiler implementer, it was unclear to me whether the following should be detected as an error. shared int s = (shared int)i; /* cast error */

Dan states that this is not an error and that this case is already covered by analogy to other uses of "gratuitous casts" (my term, not the spec).

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.

```

Reported by `gary.funck` on 2012-09-20 20:08:07 - Labels added: Priority-Medium - Labels removed: Priority-Low

[Former user]

``` "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?

```

Reported by `danbonachea` on 2012-09-20 21:48:51

[Former user]

``` For completeness, I'll repeat the statement that I made in related Issue 74.

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 are valid and allowed.

```

Reported by `gary.funck` on 2012-09-21 04:18:04

[Former user]

``` While my first consideration of "shared int s = (shared int)i;" had me thinking that it would make sense to return an error, I now consider myself convinced by Dan's explanation. It seems to me to be a "if you're doing this, it's probably not doing what you think it's doing" sort of thing.

I may be mistaken, but my impression was that a Rationale document would primarily be intended for implementers, not as a UPC Programming Guide. In my mind, the latter isn't a bad idea and, possibly in Wiki form, could be a good way for UPC users to keep up with the changes of the UPC 1.3 spec (and beyond...). Maybe that's what's meant by the Rationale doc anyway. ```

Reported by `nspark.work` on 2012-09-21 19:34:46

[Former user]

``` In the last telecon, the attendees agreed that the top-level "shared" type qualifier on right-hand side values was meaningless but not an error, as explained in Comment 2 and 8. The consensus was that No change to the UPC Spec document and Add clarification and examples in the Rationale document. ```

Reported by `[e-mail]` on 2012-10-01 16:51:06 - Status changed: `Accepted`

[Former user]

Gary agreed on the 11/29 that this is Rejected.

Reported by danbonachea on 2012-11-29 19:37:23 - Status changed: Rejected