<br><tt><font size=2>> >> * integer,
save :: U(10)[N,*] !<-- but do we intend to allow<br>
> >> this? I have difficulties in finding constraints/rules
that forbid this*<br>
> >><br>
> >> <br>
> ><br>
> > This is allowed. The array U has the same size on all images,
and the<br>
> > size is known at compile time. The [N,*] only affects how
the image<br>
> > numbers are computed in references within the subroutine. This
case is<br>
> > discussed at [92:24-26].<br>
> > <br>
> Frankly, this looks like shockingly bad design. Like Jim, I
never <br>
> imagined that something with variable bounds could be static, even
if <br>
> the size were constant.<br>
</font></tt>
<br>
<br><tt><font size=2>Same shock today here finding this out. Although
it's not much of an implementation issue, the simple fact that a piece
of static memory can be declared differently from one run to another, from
one image to another, is quite appalling. It seems we just handed
bad programmers a huge ammunition. One can *smartly* devise asymmetrically
coshaped coarrays on different images and play all kinds of games with
that. This blows away the symmetrical attribute (or simplicity) I've
always associated with coarrays. All in a sudden UPC seems not a
bad language at all since the asymmetrical nature of a shared array can
be better regulated than this. If cobounds provide nothing more than
a shrewd way to compute image index, then what is the point to have cobounds
and corank? It may make things much easier if corank has to be 1
and colbound must be 1. Maybe we should stay with MPI after all.</font></tt>
<br>
<br>
<br><font size=2 face="sans-serif">Jim Xia<br>
<br>
XL Fortran Compiler Test<br>
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7<br>
Phone (905) 413-3444 Tie-line 313-3444<br>
email: jimxia@ca.ibm.com<br>
D2/YF7/8200 /MKM<br>
<br>
</font><a href=http://www.ibm.com/software/awdtools/fortran/xlfortran><font size=2 face="sans-serif">http://www.ibm.com/software/awdtools/fortran/xlfortran</font></a>
<br>
<br>