Clarification: can the [*] layout qualifier be applied to a typedef?

[Former user]

Originally reported on Google Code with ID 71

Given:

  typedef shared [*] int int_type;
  int_type arr[3*THREADS];

GUPC issues the following error:

error: a UPC layout qualifier of '[*]' requires that the array size is either an integral
constant or an integral multiple of THREADS

However, it isn't clear whether version 1.2 of the UPC specification prohibits this.

This of course is allowed:

  typedef shared [3] int int_type;
  int_type arr[3*THREADS];

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

[Former user]

``` As I noted in issue #72, there is some "use" to applying layout qualifiers to scalars. I don't see the case for '[*]' being any different than any other layout when applied to a scalar (treated as an array of 1 element for the purposes of interpreting '[*]'). So, I would say that issue #71 should be resolved however issue #72 is decided: either ALL layout qualifiers should be legally applicable to scalars or none. ```

Reported by `[e-mail]` on 2012-07-17 22:39:42

[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:18:38

[Former user]

``` Summary: This issue is a similar problem to Issue 72, the only difference is the special layout qualifier "[*]". The typedef in the example "typedef shared [*] int int_type;" is just creating an alias of the type but not actually declaring or defining any arrays. So I think the "typedef" should not cause an error.

It is useful to allow "[*]" on a scalar Type, e.g., "typedef shared [*] int int_type;".

It is erroneous and meaningless to apply "[*]" on a scalar Variable, e.g., "shared [*] int i;".

Recommendation: No change to the spec document and close the issue.

```

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

[Former user]

``` The disposition of "No change" does not provide additional guidance to the implementer of a UPC translator. As noted in the original prbolem summary, I was unable to find definitive language on how this constuct should be translated:

typedef shared [*] int int_type; int_type arr[3*THREADS];

If we take the point of view (asserted elsewhere in other issues where we discussed the '[*]' layout qualifier, we seemed to agree that '[*]' should be "completed" (my term, not the spec.) in the declaration where it appears. Above, when '[*]' appears in a typedef, it isn't clear to me how the compiler can do that. This is the motivation for GUPC's handling of this use case as an error.

If we accept that "It is useful to allow "[*]" on a scalar Type", then a UPC compiler will have to defer the calculation of the block factor implied by the later use of the typedef which contains the "[*]". This is a distinctly different mechanism than computing the value of "[*]" where it appears.

Perhaps after further discussion, I will understand this issue more clearly and resolve some potential mis-understanding of the consensus interpretation of the spec.

However, on the basis of what I have reviewed so far, I recommend that "[*]" be treated as an error when applied to a scalar type, or to a type where the value of [*] cannot be computed when the type is defined.

```

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

[Former user]

``` I think the real underlying issue here is whether it should be permitted to use [*] in a typedef, because prior to declaration the automatic blocksize cannot be calculated. I've modified the summary to reflect this. The question of shared qualifiers (with any layout) applied to scalar declarations remains the topic of issue 72, so please take discussion of that issue there.

Allowing [*] in typedef brings up another nasty issue I haven't seen mentioned, specifically what is the correct behavior of this:

typedef shared [*] int int_type; printf("%i",upc_blocksizeof(int_type))

There are no constraint violations here, because int_type is a shared type and is not currently defined as an incomplete type by any rule in C99 or UPC: however the compiler has no way to give a meaningful answer here. I don't like the idea of adding a new flavor of incomplete type based on automatic blocksize, which is basically what Gary is alluding to in comment 6. For one thing, C99 prohibits declaring an array with an incomplete element type, so we'd need an exception for that rule as well to handle the only meaningful usage case of [*].

We already prohibit the use of [*] in pointers by 6.5.1.1-6:

"A layout qualifier of [*] shall not appear in the declaration specifiers of a pointer type."

specifically to prevent type-compatibility problems when casting/assigning pointers to this pseudo-incomplete type.

How do people feel about simply prohibiting the use of [*] in a typedef? It seems like a nasty programming practice anyhow, so the effect on real codes should be minimal (especially since some compilers already consider it an error).

Proposal: Add a constraint to 6.5.1.1:

"A layout qualifier of [*] shall not appear in the declaration specifiers of a declaration whose storage-class specifier is typedef."

```

Reported by `danbonachea` on 2012-09-20 22:18:09

[Former user]

``` As an implementer I support Dan'd proposal to outlaw "[*]" in a typedef, with the caveat that I'll back down if any body can show an example of how it would be useful (and well defined) in a non-contrived UPC code.

```

Reported by `[e-mail]` on 2012-09-20 22:33:38

[Former user]

``` I agree this should be outlawed. I can see no useful cases and several problems.

```

Reported by `brian.wibecan` on 2012-09-20 22:50:00

[Former user]

``` I agree with Dan's proposal (in comment 7) which is to disallow [*] in a typedef.

I do still wonder about this use case however:

shared [*] int x;

```

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

[Former user]

``` I have no problem with disallowing "[*]" in typedef. I just want to point out that something like the following would also be invalid under this condition:

typedef shared [*] int Int_Array_Type[3*THREADS];

```

Reported by `[e-mail]` on 2012-09-21 17:18:26

[Former user]

```

I just want to point out that something like the following would also be invalid under this condition:

typedef shared [*] int Int_Array_Type[3*THREADS];

Correct - this is another good example of why this should be disallowed. In the declaration above, the blocksize value for [*] STILL cannot be computed at the typedef, because the user can do something like this:

Int_Array_Type A[100];

Where the correct final blocksize of [*] is 300, not 3. I believe that in all cases of [*] appearing in a typedef, it is impossible for the compiler to compute a blocksize which is guaranteed to be correct for all possible uses of that type.

```

Reported by `danbonachea` on 2012-09-21 17:55:21

[Former user]

``` We seem to have sufficient consensus for an official change proposal - mailed 9/21/2012.

Description: ------------------ This issue requests prohibiting the appearance of [*] in a typedef. The primary reason is the blocksize cannot be computed at the typedef, only at array declarations using the defined type - so amongst other things its impossible in general to determine type compatibility of expressions involving the defined type. Such a typedef could also be used to circumvent the existing prohibition against [*] appearing in a pointer type, which has long been prohibited for similar reasons.

Proposed Change: ------------------------- --- upc-language.tex (revision 119) +++ upc-language.tex (working copy) @@ -491,6 +493,11 @@ \np A layout qualifier of [*] shall not appear in the declaration specifiers of a pointer type.

+\np \xadded[id=DB]{71}{ + A layout qualifier of [*] shall not appear in the declaration specifiers of + a declaration whose storage-class specifier is typedef. + } + \np A layout qualifier shall not appear in the type qualifiers for the referenced type in a pointer to void type.

```

Reported by `danbonachea` on 2012-09-21 18:48:20 - Status changed: `PendingApproval` - Labels added: Consensus-High - Labels removed: Consensus-Low

[Former user]

```

I do still wonder about this use case however:

shared [*] int x;

I think this case is already fully defined by the semantics of [*] in 6.5.1.1:

"If the layout qualifier is of the form ‘[ * ]’, the shared object is distributed as if it had a block size of ( sizeof(a) / upc_elemsizeof(a) + THREADS - 1 ) / THREADS, where ‘a’ is the array being distributed."

and 6.4.1.4: For non-array objects, upc_elemsizeof returns the same value as sizeof.

so that defines the blocksize in this case to be 1.

```

Reported by `danbonachea` on 2012-09-21 20:16:27

[Former user]

``` I agree that Dan's comment #14 demonstrates the semantics of '[*]' applied to scalars is entirely well defined by the existing spec language, thus answering Gary's concern in comment #10.

I am not opposed to adding this to some list of advice to users/implementers. ```

Reported by `[e-mail]` on 2012-09-21 22:13:26

[Former user]

these issues have all reached the end of their 4-week comment period 
and were accepted into the working draft at the 10/31 telecon.
Committed SVN r181

Reported by danbonachea on 2012-10-31 20:49:32 - Status changed: Ratified