Clarification: how is an empty layout qualfier, or a qualifier of [1] handled when present in a series of qualifiers, or via a typedef chain?

[Former user]

Originally reported on Google Code with ID 69

Consider the following:

shared shared [1] int A[THREADS];

After the first occurrence of 'shared' there is an empty layout qualifier, which implies
a value of [1].  Is this duplicative w. r. t. to the second explicit layout qualifier
of [1]?

How about the following:

shared shared [3] int A[3*THREADS];

does the value [3] over-ride the previous empty layout qualifier?

Is the following equivalent, or somehow different?

shared [1] shared [3] int A[3*THREADS];

This issue is related to issue #68.

Reported by gary.funck on 2012-07-17 20:22:59

[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'll take ownership of this issue for the purpose of giving the 2-minute presentation at the next spec meeting (since it forms a pair w/ #68 which I just grabbed).

-Paul ```

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

[Former user]

``` Summary in lieu of the "2 minute" presentation on today's call:

The point of #68 is to allow SAME shared layout qualifier to be repeated. The question in THIS issue, as I understand it, is how to apply "sameness" when the shared qualifier is present without an explicit layout qualifier. Therefore, this issue may become "moot" if #68 is rejected or substantially modified.

My proposal on this is to state that for the purpose of determining if a duplicate shared qualifier is acceptable or erroneous one must treat a missing layout qualifier as "[1]". This is just restarting the manner in which this case is treated elsewhere, and therefore satisfies the "principle of least surprise".

By examples: OK: shared shared int a[THREADS] OK: shared [1] shared int b[THREADS] OK: shared shared [1] int c[THREADS] BAD: shared [1] shared [3] int d[THREADS] BAD: shared shared[3] int e[THREADS] BAD: shared [3] shared int f[THREADS]

Any disagreement with the OK/BAD examples? ```

Reported by `[e-mail]` on 2012-09-21 21:29:07

[Former user]

``` Another related example not to forget:

shared strict relaxed int x;

```

Reported by `ga10502` on 2012-09-26 20:39:21

[Former user]

``` Notes from the 2012.09.26 spec wg call.

This issue may become irrelevant if issue #68 is resolved in favor of NOT supporting idempotency of the "shared" qualifier.

However, IF "shared" is idempotent then we DID reach consensus that "shared" with NO blocksize would be equivalent to "shared [1]" just as in all other instances (except possibly "shared void *" for which Dan will enter a new issue).

Changing to Consensus-High Changing to Priority-Low (since we seem to agree that programs "should go there") Marking as "blocked on" issue #68. ```

Reported by `[e-mail]` on 2012-09-26 21:18:41 - Labels added: Priority-Low, Consensus-High - Labels removed: Priority-Medium, Consensus-Low - Blocked on: #68

[Former user]

``` George wrote:

Another related example not to forget: shared strict relaxed int x;

George, I am not sure what point you are trying to make. If we don't already state that "relaxed" and "strict" cannot both qualify the same type/object/reference then that is probably a distinct issue. ```

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

[Former user]

``` Re comment 6:

I retract the question I raised in the call regarding (shared void *) - it turns out this is already covered by UPC 6.5.1.1-8:

"A layout qualifier shall not appear in the type qualifiers for the referenced type in a pointer to void type."

So we already prohibit types like (shared [10] void *) and even (shared [1] void *). Whatever wording is used to resolve this issue may need to include a special case for the generic pointer-to-shared, since that is the one case where a "bare" (shared) is not equivalent to (shared [1]), as the first is permitted and the second is prohibited.

```

Reported by `danbonachea` on 2012-09-26 22:27:42

[Former user]

At the 2/11/13 telecon, it was agreed to postpone these issues to 1.4.

Reported by danbonachea on 2013-02-11 20:25:26 - Labels added: Milestone-Spec-1.4 - Labels removed: Milestone-Spec-1.3