Constrain sizeof a UPC shared type or object to the range of size_t

Originally reported on Google Code with ID 13 ``` This proposal is responsive to issues 5, 38, and 39.

5. Should a upc_size_t type be defined as the return type of size(T) where T is a UPC shared type, similarly for the various upc_*sizeof() functions. Note that on a 32−bit target, size_t may not express the full range of the size of the target type, due to thread multiple. Is this an error, undefined, or should a new, larger type be defined to express the range of the size quantity?

38. What happens when the value of sizeof() potentially exceeds size_t, for example when UPC is implemented on a 32−bit platform, but lets the user refer to shared arrays that exceed the 32−bit limits of the compiler otherwise defined?

39. What happens when a UPC shared array is declared that expresses a dimension that exceeds the normal range defined for an array dimension when, for example, implemented on a 32−bit target?

The gist of these issues is illustrated by the example UPC program shown below.

include <stddef.h>
include <locale.h>
include <upc.h>
include <stdio.h>

define BIG_ALLOC (256*1024*1024) shared int A[THREADS*BIG_ALLOC];

int main() { if (MYTHREAD == 0) { setlocale(LC_ALL, "en_US"); printf ("Declared size of A = %'lld\n", (long long)THREADS * BIG_ALLOC * sizeof(int)); printf ("sizeof(A) = %'lld\n", (long long)sizeof(A)); } }

When this program is compiled with GUPC on a 32-bit target with a static value of THREADS=1, it compiles without complaint. But when compiled with THREADS=2 it results in an error. This error is consistent with GCC's behavior when compiling a "C" program that declares a similarly sized 'int' array.

centos6-32$ upc -fupc-threads-1 -o big-array big-array.c centos6-32$ upc -fupc-threads-2 -o big-array big-array.c big-array.c:7:12: error: size of array ‘A’ is too large shared int A[THREADS*BIG_ALLOC]; ^

Things get interesting when the program is compiled with dynamic threads and then the resulting program is executed with 1, 2, or 4 threads.

centos6-32$ upc -o big-array big-array.c centos6-32$ big-array -n1 Declared size of A = 1,073,741,824 sizeof(A) = 1,073,741,824 centos6-32$ big-array -n2 Declared size of A = 2,147,483,648 sizeof(A) = 2,147,483,648 centos6-32$ big-array -n4 Declared size of A = 4,294,967,296 sizeof(A) = 0

It is interesting to note that UPC allowed the declaration of a shared array that is larger than the compiler would have allowed when THREADS=2 is specified at compilation time. The value of 0 printed when THREADS=4 is due to fact that the size value exceeded the range of 'size_t' (32 bits).

Although (by compiling with dynamic threads) it may be possible to declare arrays larger than the compiler would allow if the same value of THREADS were supplied at runtime, this "feature" is likely of little practical use due to the limitations of the underlying architecture and the compiled code. One might contemplate an implementation where 64-bit shared pointer arithmetic was used to implement shared array indexing, and a new type 'upc_size_t' were introduced to accommodate the large potential range of the index value, but this seems of limited value because probably at this juncture almost all HPC (and UPC) applications target a 64-bit architecture.

This proposal states:

The UPC language specification will not be extended to allow compiled UPC programs to exceed the underlying restrictions imposed by the implementation for equivalent strictly serial "C" programs, in the area of array declarations, array indexing, shared pointer arithmetic and the value returned by 'size_t'.

An implementation is still free to provide extensions that might remove some/all of these restrictions; there will be no explicit accommodation in the UPC language specification for these

```

Reported by `gary.funck` on 2012-05-20 22:50:42

Comments (2)