On Saturday 16 July 2011 17:25:36 Tobias Burnus wrote: > Mikael Morin wrote: > > let me understand one thing about coarray scalars: despite their name, > > they are arrays, right? > > Yes and no. In terms of the language, they are scalars - but they have a > codimension, e.g. > integer, save :: A[4:6, 7:*] > is a scalar variable on each image, but it has a coarank of 2 with > lcobound(A) == [4, 7] and ucobound(A, dim=1) == 7. ucobound(A, dim=1) == 6 ? Otherwise I'm even more confused.
> > Then when you do in gfc_conv_array_ref: > > > > + if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se->expr))) > > + se->expr = build_fold_indirect_ref (gfc_conv_array_data > > (se->expr)); [...] > > > > return; > > > > you are returning scalar[1] instead of scalar (== scalar[this_image()]) > > or scalar[whatever_image_selector], aren't you? > > Well, the current implementation supports effectively only a single > image - for -fcoarray=single on purpose and for -fcoarray=lib because it > has not yet been implemented. > > Later, one has to add some function call for "scalar[<image_numer>]" > while "scalar" itself is the local variable and can be handled as above. Ah, OK; that's where I was misunderstanding coarrays. I was thinking that a (possibly out of date) copy of remote images was available locally, like a normal array; and with any network exchanges happening during the SYNC* calls only. In fact network traffic happens anywhere there are square brackets, and SYNC* are mere iddle waits, right? > The expression of "scalar" ends up having expr->ref->type == REF_ARRAY > with dimen_type == DIMEN_THIS_IMAGE. That way one can distinguish a > reference to the local coarray and to a remote coarray (coindexed > variable); note that "coarray[this_image()]" also counts as > remote/coindexed. While it seems to work well, we would probably have gained some clarity by using a separate struct for coarray references. For example with the current scheme, array[1,2] has type ARRAY_FULL, but some dimen_type are of type DIMEN_ELEMENT. Odd. > > Sorry for the delay; it seems that the more it goes, the more you are the > > only one who can maintain coarray stuff. :-( > > Well, Daniel Carrera develops into an trans*.c, allocate, > libgfortran/caf/ expert :-) > Thanks for all the clarifications. Patch is OK (I guess). Mikael
