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

[Former user]

Originally reported on Google Code with ID 68

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

Reported by gary.funck on 2012-07-17 20:14:55

[Former user]

``` This issue is related to issue #69.

```

Reported by `gary.funck` on 2012-07-17 20:23:25

[Former user]

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

Reported by `[e-mail]` on 2012-07-17 20:31:09

[Former user]

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

```

Reported by `gary.funck` on 2012-07-17 21:27:28

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

-Paul ```

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

[Former user]

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

Reported by `[e-mail]` on 2012-09-21 21:27:40

[Former user]

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

Reported by `[e-mail]` on 2012-09-26 21:18:11 - Labels added: Priority-Low - Labels removed: Priority-Medium

[Former user]

Reported by `[e-mail]` on 2012-09-26 21:18:42 - Blocking: #69

[Former user]

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.

Reported by danbonachea on 2013-01-24 07:43:32

[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