This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.
- From: Andre Vehreschild <vehre at gmx dot de>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>, GCC-Patches-ML <gcc-patches at gcc dot gnu dot org>, GCC-Fortran-ML <fortran at gcc dot gnu dot org>
- Date: Wed, 30 Nov 2016 15:35:29 +0100
- Subject: Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.
- Authentication-results: sourceware.org; auth=none
- References: <20161122204650.03893214@vepi2> <20161128193330.55c0802a@vepi2> <CAGkQGiLPGzB-8KC4opMRdvOkJW5wxpx03-m7k9g3PUkQ581EFg@mail.gmail.com> <20161130143007.235e8c73@vepi2> <CAKwh3qjrtnz9_obQLr2jLH6SremaP=-nUSfc=MgAAGGhsh3vNg@mail.gmail.com> <20161130152246.03eec0fd@vepi2>
Hi all,
on IRC:
15:28:22 dominiq: vehre: add /* FALLTHROUGH */
Done and committed as obvious as r243023.
- Andre
On Wed, 30 Nov 2016 15:22:46 +0100
Andre Vehreschild <vehre@gmx.de> wrote:
> Janus,
>
> those fallthroughs are fully intentional and each and everyone is documented.
> When you can tell me a way to remove those false positive warnings I am happy
> to do so, when it comes at no extra costs at runtime.
>
> - Andre
>
> On Wed, 30 Nov 2016 14:48:38 +0100
> Janus Weil <janus@gcc.gnu.org> wrote:
>
> > Hi Andre,
> >
> > after your commit I see several warnings when compiling libgfortran
> > (see below). Could you please fix those (if possible)?
> >
> > Thanks,
> > Janus
> >
> >
> >
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c: In function
> > ‘_gfortran_caf_is_present’:
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2949:8: warning:
> > this statement may fall through [-Wimplicit-fallthrough=]
> > if (riter->next == NULL)
> > ^
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2952:3: note: here
> > case CAF_ARR_REF_VECTOR:
> > ^~~~
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2976:8: warning:
> > this statement may fall through [-Wimplicit-fallthrough=]
> > if (riter->next == NULL)
> > ^
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2979:3: note: here
> > case CAF_ARR_REF_VECTOR:
> > ^~~~
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2949:8: warning:
> > this statement may fall through [-Wimplicit-fallthrough=]
> > if (riter->next == NULL)
> > ^
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2952:3: note: here
> > case CAF_ARR_REF_VECTOR:
> > ^~~~
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2976:8: warning:
> > this statement may fall through [-Wimplicit-fallthrough=]
> > if (riter->next == NULL)
> > ^
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2979:3: note: here
> > case CAF_ARR_REF_VECTOR:
> > ^~~~
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c: In function
> > ‘_gfortran_caf_get_by_ref’:
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:1863:29: warning:
> > ‘src_size’ may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
> > if (size == 0 || src_size == 0)
> > ~~~~~~~~~^~~~
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c: In function
> > ‘_gfortran_caf_send_by_ref’:
> > /home/jweil/gcc/gcc7/trunk/libgfortran/caf/single.c:2649:29: warning:
> > ‘src_size’ may be used uninitialized in this function
> > [-Wmaybe-uninitialized]
> > if (size == 0 || src_size == 0)
> > ~~~~~~~~~^~~~
> >
> >
> >
> >
> > 2016-11-30 14:30 GMT+01:00 Andre Vehreschild <vehre@gmx.de>:
> > > Hi Paul,
> > >
> > > thanks for the review. Committed with the changes requested and the one
> > > reported by Dominique on IRC for coarray_lib_alloc_4 when compiled with
> > > -m32 as r243021.
> > >
> > > Thanks for the review and tests.
> > >
> > > Regards,
> > > Andre
> > >
> > > On Wed, 30 Nov 2016 07:49:13 +0100
> > > Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> > >
> > >> Dear Andre,
> > >>
> > >> This all looks OK to me. The only comment that I have that you might
> > >> deal with before committing is that some of the Boolean expressions,
> > >> eg:
> > >> + int caf_dereg_mode
> > >> + = ((caf_mode & GFC_STRUCTURE_CAF_MODE_IN_COARRAY) != 0
> > >> + || c->attr.codimension)
> > >> + ? ((caf_mode & GFC_STRUCTURE_CAF_MODE_DEALLOC_ONLY) != 0
> > >> + ? GFC_CAF_COARRAY_DEALLOCATE_ONLY
> > >> + : GFC_CAF_COARRAY_DEREGISTER)
> > >> + : GFC_CAF_COARRAY_NOCOARRAY;
> > >>
> > >> are getting be sufficiently convoluted that a small, appropriately
> > >> named, helper function might be clearer. Of course, this is true of
> > >> many parts of gfortran but it is not too late to start making the code
> > >> a bit clearer.
> > >>
> > >> You can commit to the present trunk as far as I am concerned. I know
> > >> that the caf enthusiasts will test it to bits before release!
> > >>
> > >> Regards
> > >>
> > >> Paul
> > >>
> > >>
> > >> On 28 November 2016 at 19:33, Andre Vehreschild <vehre@gmx.de> wrote:
> > >> > PING!
> > >> >
> > >> > I know it's a lengthy patch, but comments would be nice anyway.
> > >> >
> > >> > - Andre
> > >> >
> > >> > On Tue, 22 Nov 2016 20:46:50 +0100
> > >> > Andre Vehreschild <vehre@gmx.de> wrote:
> > >> >
> > >> >> Hi all,
> > >> >>
> > >> >> attached patch addresses the need of extending the API of the caf-libs
> > >> >> to enable allocatable components asynchronous allocation. Allocatable
> > >> >> components in derived type coarrays are different from regular
> > >> >> coarrays or coarrayed components. The latter have to be allocated on
> > >> >> all images or on none. Furthermore is the allocation a point of
> > >> >> synchronisation.
> > >> >>
> > >> >> For allocatable components the F2008 allows to have some allocated on
> > >> >> some images and on others not. Furthermore is the registration with
> > >> >> the caf-lib, that an allocatable component is present in a derived
> > >> >> type coarray no longer a synchronisation point. To implement these
> > >> >> features two new types of coarray registration have been introduced.
> > >> >> The first one just registering the component with the caf-lib and the
> > >> >> latter doing the allocate. Furthermore has the caf-API been extended
> > >> >> to provide a query function to learn about the allocation status of a
> > >> >> component on a remote image.
> > >> >>
> > >> >> Sorry, that the patch is rather lengthy. Most of this is due to the
> > >> >> structure_alloc_comps' signature change. The routine and its wrappers
> > >> >> are used rather often which needed the appropriate changes.
> > >> >>
> > >> >> I know I left two or three TODOs in the patch to remind me of things I
> > >> >> have to investigate further. For the current state these TODOs are no
> > >> >> reason to hold back the patch. The third party library opencoarrays
> > >> >> implements the mpi-part of the caf-model and will change in sync. It
> > >> >> would of course be advantageous to just have to say: With gcc-7
> > >> >> gfortran implements allocatable components in derived coarrays nearly
> > >> >> completely.
> > >> >>
> > >> >> I know we are in stage 3. But the patch bootstraps and regtests ok on
> > >> >> x86_64-linux/F23. So, is it ok for trunk or shall it go to 7.2?
> > >> >>
> > >> >> Regards,
> > >> >> Andre
> > >> >
> > >> >
> > >> > --
> > >> > Andre Vehreschild * Email: vehre ad gmx dot de
> > >>
> > >>
> > >>
> > >
> > >
> > > --
> > > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: libgfortran/caf/single.c
===================================================================
--- libgfortran/caf/single.c (Revision 243021)
+++ libgfortran/caf/single.c (Arbeitskopie)
@@ -2949,6 +2949,7 @@
if (riter->next == NULL)
break;
/* else fall through reporting an error. */
+ /* FALLTHROUGH */
case CAF_ARR_REF_VECTOR:
case CAF_ARR_REF_RANGE:
case CAF_ARR_REF_OPEN_END:
@@ -2976,6 +2977,7 @@
if (riter->next == NULL)
break;
/* else fall through reporting an error. */
+ /* FALLTHROUGH */
case CAF_ARR_REF_VECTOR:
case CAF_ARR_REF_RANGE:
case CAF_ARR_REF_OPEN_END:
- References:
- [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.
- Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.
- Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.
- From: Paul Richard Thomas
- Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.
- Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.
- Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.