This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] First steps to array descriptor reform
- From: Tobias Burnus <burnus at net-b dot de>
- To: Toon Moene <toon at moene dot org>
- Cc: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, fortran at gcc dot gnu dot org, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 07 Jun 2009 22:00:31 +0200
- Subject: Re: [Patch, fortran] First steps to array descriptor reform
- References: <339c37f20906071042s6beb378dk1bb909e5bb437f2a@mail.gmail.com> <4A2C098D.6010101@moene.org>
Toon Moene wrote:
>> The enclosed patch is a first step towards the implementation of the
>> gfortran array descriptor reform. However, this patch does nothing
>> than to rearrange the API to the present array descriptor by replacing
>> gfc_conv_descriptor_xxx with gfc_conv_descriptor_xxx_get and
>> gfc_conv_descriptor_xxx_set for xxx = [offset, stride, lbound,
>> ubound].
Good!
> Does this have any effect on Tobias Burnus' work on coarrays ?
I don't think it has much effect on the single-image support I am
working on. Presumably, one should add a "int corank" element to check
at run time whether the coranks agree when passing an actual coarray to
a dummy coarray. Any for a shared-memory implementation, "int corank"
could be also useful. As adding "int corank" will break the current ABI,
the effect of the array-descriptor reform (which will break the ABI) is
positive.
Thomas König wrote:
> > (i) Apply the attached patch;
> > (ii) Modify the descriptor in the frontend and the library.
> > (iii) Ensure that there is no runtime performance loss and submit at
> > this stage so that the API change occurs as early as possible; and
> > (iv) FIx all the associated PRs.
>
> Makes sense to me, this way, with one open point...
>
>
> So far, the array descriptor macro patches are implemented on
> fortran-dev, so it would make sense to either
>
> a) do your steps (i) to (iv) on fortran-dev, then move the whole thing
> to trunk, or
>
> b) merge fortran-dev to trunk completely before step (ii).
I think one could also do a hybrid version: Apply (i) or (i) plus
libgfortran array-descriptor macros to the trunk, do (ii)+(iii) at the
branch, merge (ii)+(iii) and continue on the trunk.
* * *
Paul, what's you plan with regards to -fwhole-file? Do you want to fix
it completely or do a partial merge before everything is working? And
what is you current agenda with regards to -fwhole-file and the array
descriptor work?
Tobias