Add constraint: a declaration of an array with indefinite block size must have compile-time constant dimensions

[Former user]

Originally reported on Google Code with ID 15

This proposal is responsive to issue 36.

36. Regarding upc_localsizeof in a dynamic threads environment, this     

  typedef is compiled without complaint:
  typedef shared [] int b3_t[3*THREADS];

but is diagnosed as an error when instantiated:

   b3_t B;

Is this the expected behavior? See: https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=2960#c4

The cited bug report comment notes that:

on p26 of the UPC 1.2 spec, the "EXAMPLE 2" says:

 7  EXAMPLE 2: declarations allowed only in static THREADS translation
    environment:
       shared int x [10+THREADS];
       shared [] int x [THREADS];    <<<---
       shared int x [10];

And that there appeared to be no explicit constraint in the specification to support
this restriction.

Constraint 2 in the same section 6.5.2.1 states:

When a UPC program is translated in the dynamic THREADS environment
and an array with shared-qualified elements is declared with definite blocksize, the
THREADS expression shall occur exactly once in one dimension of the array declarator
(including through typedefs). Further, the THREADS expression shall only occur either
alone or when multiplied by an integer constant expression.

The lead in states "is declared with definite blocksize", which does not appear to
preclude an indefinite block size.  The discussion of layout qualifiers (block sizes)
in section 5.1.1.1 does not shed further light on this use case.

Proposal:

Add an explicit constraint in the UPC specification in section 6.5.2.1 to state that
it is an error to declare an array with indefinite block size when compiled in a dynamic
THREADS environment.

Reported by gary.funck on 2012-05-21 00:26:50

[Former user]

``` The open issue description cites the following example.

typedef shared [] int b3_t[3*THREADS]; b3_t B;

and notes that at present, the compiler accepts the type definition of 'b3_t', but issues an error when that type definition is used in the declaration of 'B'.

Per this proposal, both the type definition and its use are erroneous when compiled in a dynamic THREADS environment.

```

Reported by `gary.funck` on 2012-05-21 00:33:30

[Former user]

``` Unless I'm missing something, the problem is not that the array declaration has indefinite block size, but that it has both indefinite block size and a THREADS dimension. The following is perfectly normal, and potentially useful, in a dynamic THREADS environment:

shared [] int x[30];

How about making it clear that that an array declared with indefinite block size must have no THREADS dimensions in the dynamic THREADS environment? ```

Reported by `brian.wibecan` on 2012-05-22 20:56:28

[Former user]

``` Brian wrote: "How about making it clear that that an array declared with indefinite block size must have no THREADS dimensions in the dynamic THREADS environment?"

Good point, and correct that the use of an indefinite block size in combination with an array dimension that does not refer to THREADS is both useful and allowed.

```

Reported by `gary.funck` on 2012-05-22 21:14:52

[Former user]

``` Just to clarify/reiterate since we don't all re-read the issues when these comments arrive in email. The issue at hand is that on p26 of the UPC 1.2 spec, the "EXAMPLE 2" says:

7 EXAMPLE 2: declarations allowed only in static THREADS translation environment: shared int x [10+THREADS]; shared [] int x [THREADS]; <<<--- shared int x [10];

but we cannot currently cite specific constraints that actually disallow the definition marked with "<<<---" above.

So, I beleive the question is NOT "should we disallow" as the Example in the existing spec already shows that was the intent. So, to me the question is only what changes are required to clarify that intent. As Brian has observed the initial proposal accidentally prohibits a useful case it was not intended to.

So, I'd like to amend the proposal to prevent THREADS in the dimensions of an indefinitely-blocked array in a dynamic threads environment while allowing it for static threads. I think the following meets that goal:

Add an explicit constraint in the UPC specification in section 6.5.2.1 to state that a declaration of an array with indefinite block size must have compile-time constant dimensions.

```

Reported by `[e-mail]` on 2012-05-23 20:52:07

[Former user]

``` I support Pual's suggestion: "Add an explicit constraint in the UPC specification in section 6.5.2.1 to state that a declaration of an array with indefinite block size must have compile-time constant dimensions."

Tagged with milestone: 1.3 ```

Reported by `gary.funck` on 2012-06-28 19:57:24 - Labels added: Milestone-Spec-1.3

[Former user]

Reported by `gary.funck` on 2012-06-28 19:59:13

[Former user]

``` Set default Consensus to "Low". ```

Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low

[Former user]

``` Mass change "Accepted" issues which haven't seen activity for over a month back to "New", for telecon discussion. ```

Reported by `danbonachea` on 2012-10-04 11:36:12 - Status changed: `New`

[Former user]

``` Paul's suggestion: "Add an explicit constraint in the UPC specification in section 6.5.2.1 to state that a declaration of an array with indefinite block size must have compile-time constant dimensions."

One could interpret C99 6.7.5.2 to already imply this requirement. Specifically, C99 6.7.5.2-2 prohibits variable-length arrays with static storage duration, thereby implying via 6.7.5.2-4 a requirement that in an array declarator with static storage duration (which includes all statically-allocated shared arrays) "the size is an integer constant expression and the element type has a known constant size".

However, I agree this is very roundabout logic, especially in light of the existing special case for definitely-blocked arrays in the dynamic threads environment (where THREADS is required to appear exactly once, in a constant expression linear in THREADS). So it seems worthwhile for the case of indefinitely-blocked arrays in the dynamic environment to be explicitly clarified. Furthermore, I think what needs to be clarified in this case is not that the dimensions must be constant (which as I've argued is already implied by C99), but more specifically that (unlike definitely-blocked arrays) it may not include THREADS.

Footnote 18 in the current spec (the footnote for the text quoted in the original comment) states: "This implies the THREADS expression shall not appear anywhere in the declarator of a shared array with indefinite blocksize under the dynamic THREADS environment."

I think this is exactly the restriction we are looking for, although I don't believe it is currently implied by the body text it decorates. I think the solution is to remove the "this implies" and promote this footnote into the main body.

Proposal mailed on 10/5:

--- upc-language.tex (revision 143) +++ upc-language.tex (working copy) @@ -665,11 +673,19 @@ shall only occur either alone or when multiplied by an integer constant expression.\footnote{In the {\em static THREADS} environment THREADS is an integer constant expression, and is therefore valid in - all dimensions.} \footnote{This implies the THREADS expression - shall not appear anywhere in the declarator of a shared array with - indefinite blocksize under the {\em dynamic THREADS} environment.} + all dimensions.}

+\np \xadded[id=DB]{15}{ + The THREADS expression + shall not appear anywhere in the declarator of a shared array with + indefinite blocksize under the {\em dynamic THREADS} environment. + }

```

Reported by `danbonachea` on 2012-10-05 08:51:00 - Status changed: `PendingApproval` - Labels added: Consensus-High - Labels removed: Consensus-Low

[Former user]

Ratified at the 11/9/12 telecon.

Reported by danbonachea on 2012-11-09 22:52:20 - Status changed: Ratified

[Former user]

Reported by danbonachea on 2013-03-18 16:23:07 - Blocking: #95