Fix ambiguities and inconsistencies involving multi-dimensional shared arrays

Originally reported on Google Code with ID 85
{ This issue was spun off of issue 3 comment 41. }

In general, there are a lot of places in the 1.2 spec that assume all shared arrays
have a single dimension and are ambiguous if they have more than one dimension.  For
instance (emphasis mine),

3.2.3.1
"shared array
an array with ELEMENTS that have shared qualified type"

3.9.1 
"phase
an unsigned integer value associated with a pointer-to-shared which indicates the ELEMENT-offset
within an affinity block; ..."

6.4.2.4
"In addition, the correspondence between shared and local addresses and arithmetic
is defined using the following constructs:

  T *P1, *P2;
  shared T *S1, *S2;

  P1 = (T*) S1; /* allowed if S1 has affinity to MYTHREAD */
  P2 = (T*) S2; /* allowed if S2 has affinity to MYTHREAD */"

Assume T is defined as

  typedef int T[2];

Then it is erroneous to use the results of those casts in the general case, as (*P1)[1]
(or (*P2)[1]) may point to unused memory as the shared object may have no additional
elements on the local thread.

6.4.2.5
"...The expression ((ptrdiff_t) upc_addrfield(S2) - (ptrdiff_t) upc_addrfield(S1))
shall evaluate to the same value as ((P2 - P1) * sizeof(T))"

This fails miserably if T is an array type.

6.4.3.6
"Shared objects with affinity to a given thread can be accessed by either pointers-to-shared
or pointers-to-local of that thread."

What is the affinity of a shared object that spans multiple threads?

6.5.1.1.10
"... This factor is the nonnegative number of consecutive ELEMENTS (when evaluating
pointer-to-shared arighmetic and array declarations) which have affinity to the same
thread..."

6.5.2.1.3
"ELEMENTS of shared arrays are distributed in a round robin fashion, by chunks of block-size
ELEMENTS, such that the i-th ELEMENT has affinity with thread (floor (i/block_size)
mod THREADS)"
Reported by sdvormwa@cray.com on 2012-09-13 19:38:13
Comments (5)
