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?

[GoogleCodeExporter]

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.

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

• Blocked on: Clarification: the re-specification of a same-valued layout qualifer is allowed #68

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

Original comment by [email protected] on 14 Sep 2012 at 10:09

[GoogleCodeExporter]

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?

Original comment by [email protected] on 21 Sep 2012 at 9:29

[GoogleCodeExporter]

Another related example not to forget:

shared strict relaxed int x;

Original comment by [email protected] on 26 Sep 2012 at 8:39

[GoogleCodeExporter]

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.

Original comment by [email protected] on 26 Sep 2012 at 9:18

• Added labels: Consensus-High, Priority-Low
• Removed labels: Consensus-Low, Priority-Medium
• Now blocked on: Clarification: the re-specification of a same-valued layout qualifer is allowed #68

[GoogleCodeExporter]

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.

Original comment by [email protected] on 26 Sep 2012 at 9:22

[GoogleCodeExporter]

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.

Original comment by danbonachea on 26 Sep 2012 at 10:27

[GoogleCodeExporter]

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

Original comment by danbonachea on 11 Feb 2013 at 8:25

• Added labels: Milestone-Spec-1.4
• Removed labels: Milestone-Spec-1.3