The email below seems to be the most recent email on native coarray
support. Has there been any more recent work or plans for committing a
patch? Could someone tell me whether the planned feature will work on
Windows without requiring the Windows Subsystem for Linux? Asking for a
friend. :)
Damian
On Fri, Oct 16, 2020 at 7:38 AM Paul Richard Thomas via Fortran <
fortran@gcc.gnu.org> wrote:
> Hi Andre,
>
> Yes, as Thomas confirms, you are correct about the function of span.
> Unfortunately the originators of gfortran decided on strides in words for
> array descriptors rather than bytes. As far as I am aware, all the other
> vendors use lbound, stride measure and extent, with stride measure in
> bytes. Once committed to this line, allowing the F95 feature of pointers to
> components of derived type arrays necessitated the introduction of span.
> Tobias and I got a long way to do the change over to {lbound, sm, extent}
> in fortran-dev but we both ran out of availability with a long way to go.
> We did this by calculating stride in words from the new array descriptor
> and substituting it everywhere that the stride was needed. This resulted in
> ugly and inefficient repetitions of sm/element_length in array element
> addressing. When I last looked at it everything worked except coarrays,
> which I broke somewhere in libcaf.
>
> Unfortunately, I am still pressed by daytime activities so something on
> this scale is well beyond my capacity. I will be concentrating on
> regressions in the coming weeks.
>
> Nicolas, I haven't responded to your coarrays patch. Well done for this
> impressive bit of work and thanks to Andre for reviewing it. I sincerely
> hope to see it in master, sometime in the next weeks. As has been said
> elsewhere, this should be an important aid to familiarising fortran users
> with coarrays. Does anybody have access to an AMD Ryzen 32 core machine?
>
> Best regards
>
> Paul
>
>
>
>
> On Fri, 16 Oct 2020 at 10:43, Thomas Koenig <tkoe...@netcologne.de> wrote:
>
> > Am 16.10.20 um 10:45 schrieb Andre Vehreschild:
> > > Hi Thomas, hi Nicolas,
> > >
> > > I agree with you, that doing copies of array's data should be avoided,
> > but
> > > please keep in mind, that the gfc_descriptor_t is so to say "public".
> > I.e.,
> > > there are also libraries using it, that are not in the gcc repo and
> those
> > > depend on the descriptor being usable as is.
> >
> > I am quite aware of that.
> >
> > However, what can happen?
> >
> > Since the last ABI revision, we set the span. Old code calling a new
> > library will work anyway because it will do the packing / unpacking.
> > New code calling the old library is something we do not, in general,
> > support (we do add new functions to the library), but it would also work
> > because we set the span anyway.
> >
> > The only thing we cannot handle is new user code (without the temporary)
> > calling old user code (which does not handle the span). We cannot
> > change that without an ABI upgrade, but upgrading the library will
> > not be affected.
> >
> > > Furthermore, the span-member is not necessarily the size of the data
> > element in
> > > the array, right @Paul?
> >
> > That's the point of using the span.
> >
> > > Assume a structure whose data components need an odd
> > > number of bytes. Putting this structure into an array, the span-member
> > would
> > > hold the padded data size, right?
> >
> > Not the size, the distance. Fortunately, alignment requirements mean
> > that this will work out OK.
> >
> > > I am not sure about the above, therefore Paul is in copy. This is just
> > like I
> > > have memorized it (may be wrong).
> > >
> > > Anyway, my remark was more the comment not being precise or rather
> > misleading.
> > > I would expect something like "/* store byte-based strides here */".
> > Which
> > > makes it more clear, what will been done.
> >
> > OK :-)
> >
> > Thanks for looking at this!
> >
> > Best regards
> >
> > Thomas
> >
>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>
