Clarification: the re-specification of a same-valued layout qualifer is allowed

[GoogleCodeExporter]

Version 1.2 of the UPC specification at 6.5.2p6 states:

"No type qualifier list shall specify more than
one block size, either directly or indirectly
through one or more typedefs."

Consider the following:

shared [3] shared [3] int A[3*THREADS]; // Is this an error?

GUPC is inconsistent in handling this.  It rejects

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

"error: two or more layout qualifiers specified"

but accepts

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

How does shared [*] fit into this.

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

And what about the case where [1] is supplied explicitly?

  typedef shared [1] int int_type;
  shared int_type array[THREADS];

This issue ticket proposes that the same value of the layout qualifier is 
allowed and should not be diagnosed as an error/warning, independent of whether 
the value is given explicitly/implicitly, via a typedef chain, ro by 
instantiating the value of [*].

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

• Blocking: 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? #69

[GoogleCodeExporter]

This issue is related to issue #69.

Original comment by gary.funck on 17 Jul 2012 at 8:23

[GoogleCodeExporter]

The spirit of this issue is similar to
  const const float f;
and
  typedef const float c_float;
  const c_float cf;

If I understand correctly, one of the changes in C99 relative to C89 was to 
make type qualifiers idempotent (see item 29 at 
http://home.datacomm.ch/t_wolf/tw/c/c9x_changes.html )

So, if "shared [3]" is treated as a type qualifier then C99 already has an 
answer.

Original comment by [email protected] on 17 Jul 2012 at 8:31

[GoogleCodeExporter]

For completeness, the cited item 29 states:

29. Type qualifiers are idempotent, i.e., if a type qualifier appears several 
times (either directly or indirectly through typedefs) in a type specification, 
it's treated as if it appeared only once. E.g. const const int i; is equivalent 
to const int i;. (Note that in const int * const p;, this doesn't apply as the 
second const qualifies the pointer!)

I agree with Paul's interpretation of the specification, and note that neither 
of the following should generate a diagnostic:

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

This should be an error:

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

because it specifies "more than one" layout qualifier.

But what about this?

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

Is this equivalent to:

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

or somehow different?

Original comment by gary.funck on 17 Jul 2012 at 9:27

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

-Paul

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

[GoogleCodeExporter]

Summary in lieu of the "2 minute" presentation today:

Whereas:
+ UPC says we cannot specify more than one blocksize
+ C99 says one may repeat qualifiers (e.g. "const const" is OK)

It is proposed that:
1) we allow duplicate "relaxed" or "strict" qualifiers (may not require any 
spec change)
2) we clarify that "more than one" in 6.5.2p6 DOES allow for duplicate 
specifications of the SAME block size.
3) both (1) and (2) are to be permitted both directly in a 
declaration/definition and indirect via typedefs.

Gary's proposal is to include as legal the case that the block size computed 
for '[*]' is the same as an explicit block size, such as '[4]'.  This is the 
only point that I think might be controversial, because I am uncertain on can 
always perform that check at compile time.

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

[GoogleCodeExporter]

Notes from the 2012.09.26 spec wg call.

We did NOT reach a consensus on the call.  There were two view points:

View point #1) We can/should apply idempotentcy to "shared" because that is 
what C99 does, and the clarification could be made with the addition of 
"distinct" to the existing prohibition against "more than one block size".  
Some examples would then be useful to illustrate the point.  Also, if we go 
this path there are questions to be resolved about '[*]' and other cases of 
lexically-different-but-numerically-equal block sizes.

View point #2) The nature of "shared" is so different already from qualifiers 
like "const" and "volatile" (a point of discussion that occurred in issues #74 
and #75 as well) that we can/should make an exception from the idempotentcy 
rule for "shared".

Regardless of which view one takes, we *did* seem to have a consensus that 
there should NOT be a need for valid/well-written UPC code to encounter this 
situation.  Only "sloppy" use of typedefs or the pre-processor are likely to 
result in this situation. 

It also seemed uncontentious that "relaxed" and "strict" are automatically 
idempotent by C99 and no need for a clarification was voiced on the call.

Leaving at Consensus-Low
Moving to Priority-Low (since we seem to agree that programs "should go there")

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

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

[GoogleCodeExporter]

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

• Now blocking: 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? #69

[GoogleCodeExporter]

After several months we don't have consensus on a technical resolution for this 
issue and closely-related issue 69, but I think we agree the potential impact 
on well-written UPC programs is minimal.

Lacking an expedient resolution, I propose we postpone both issues for 1.4.

Original comment by danbonachea on 24 Jan 2013 at 7:43

[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