Remove shared array initialization
Originally reported on Google Code with ID 78
Consider:
shared int A[4*THREADS] = {1, 2, 3, 4, 5,
6, 7, 8, 9, 10,
11, 12, 13, 14, 15};
In a static threads compilation environment, this initializer will be valid for values
of THREADS >=4. For values of THREADS < 4,
the initializer specifices too many elements.
How might this initializer be interpreted in a dynamic THREADS compilation environment?
Obviously, we could apply the same rules as wtih the static threads compilation environment,
but if out-of-range initializers are detected as errors/warnings, this detection can
occur
only at runtime.
Consider:
shared int A[] = {1, 2, 3, 4, 5,
6, 7, 8, 9, 10,
11, 12, 13, 14, 15};
Since the dimension of A[] is determined from the initializer as 15, would this result
in a compilation error when compiled in the dynamic
THREADS environment?
Given the complexities above, might it not be simpler to disallow initialization of
shared arrays?
Reported by gary.funck
on 2012-07-18 22:00:37
Comments (7)
-
Account Deleted -
Account Deleted ``` Set default Consensus to "Low". ```
Reported by `gary.funck` on 2012-08-19 23:26:19 - Labels added: Consensus-Low
-
Account Deleted ``` Change Status to New: Requires review. ```
Reported by `gary.funck` on 2012-08-19 23:37:41 - Status changed: `New`
-
Account Deleted ``` I'll handle this one. ```
Reported by `prmerkey` on 2012-09-17 15:24:41
-
Account Deleted ``` The consensus from the 9/28 telecon is we'd like to eventually phase-out support for static initialization of shared array objects from the language. A very rough survey of implementations indicated this is already poorly or inconsistently supported in current compilers.
A few options were considered: 1. Leave it in, fix the semantic ambiguities and force everyone to fully implement it (don't think anyone advocated this position) 2. Remove it entirely in 1.3 (technically breaking backward compatibility) 3. Deprecate it in 1.3 or somehow indicate it will be phased out soon, then remove it in 1.4 or 2.0.
I don't recall discussing whether this would also apply to static initialization of non-array shared objects (scalars and aggregates). However those cases seem far simpler from an semantic and implementation standpoint (and also potentially more useful to programmers), so I would advocate leaving those in and merely phasing out shared array static initializers.
If we follow that approach, it means the examples in comment #0 would be prohibited and semantic questions regarding the interaction of initializers and blocking factors would be moot. However, we would still allow code like:
shared int dim = 100; shared void *list = NULL;
but notably also things like:
shared int * shared pdim = &dim; a pointer in shared space initialized to the address of another static shared object
shared struct { int arr[4]; } foo = { { 1,2,3,4 } }
```
Reported by `danbonachea` on 2012-10-04 11:31:00
-
Account Deleted ``` I'd like to propose that we make shared array initializers "implementation-defined" in 1.3. This allows current implementations to keep whatever support they currently provide (just requires them to document it), while warning users that this feature is not portable.
Proposal mailed 10/4/2012:
--- upc-language.tex (revision 143) +++ upc-language.tex (working copy) @@ -669,6 +677,10 @@ shall not appear anywhere in the declarator of a shared array with indefinite blocksize under the {\em dynamic THREADS} environment.}
+\np \xadded[id=DB]{78}{ + If an init-declarator that declares an array with shared-qualified elements + includes an initializer, the behavior is implementation-defined. + }
{\bf Semantics}
```
Reported by `danbonachea` on 2012-10-05 02:54:44 - Status changed: `PendingApproval`
-
Account Deleted Ratified at the 11/9/12 telecon.
Reported by
danbonachea
on 2012-11-09 22:52:21 - Status changed:Ratified
- Log in to comment
``` I can understand if others want to disallow initialization of shared arrays (either under dynamic threads, or always). However, for the sake of this issue, lets assume that we want to support this.
The best solution to this I can envision for this is to make the behavior for excess elements in a dynamic-threads environment "implementation-defined". Meaning that an implementation can do as it pleases, but must DOCUMENT what the behavior will be. To do otherwise, I fear, places unrealistic expectations on the implementer(s). ```
Reported by `phhargrove@lbl.gov` on 2012-07-18 22:05:20