Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays.

[Andre Vehreschild <vehre at gmx dot de>]

Hi all,

and another aftermatch reported by Dominique. Fixing testcase
coarray_lib_alloc_4.f90 for 32-bit. Committed as obvious as r243101. Thanks for
reporting Dominique.

- Andre

On Wed, 30 Nov 2016 16:59:39 +0100
Andre Vehreschild <vehre@gmx.de> wrote:

> Fixed -> r243034.
> 
> - Andre
> 
> On Wed, 30 Nov 2016 15:53:39 +0100
> Janus Weil <janus@gcc.gnu.org> wrote:
> 
> > Hi,
> >   
> > > on IRC:
> > > 15:28:22 dominiq:  vehre: add /* FALLTHROUGH */
> > >
> > > Done and committed as obvious as r243023.    
> > 
> > thanks. However, I still see these two:
> > 
> >   
> > >> > /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)
> > >> >                     ~~~~~~~~~^~~~    
> > 
> > Can you please fix them as well?
> > 
> > Thanks,
> > Janus
> > 
> > 
> > 
> >   
> > >> > 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    
> 
> 


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 

Index: gcc/testsuite/ChangeLog
===================================================================
--- gcc/testsuite/ChangeLog	(Revision 243100)
+++ gcc/testsuite/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,7 @@
+2016-12-01  Andre Vehreschild  <vehre@gcc.gnu.org>
+
+	* gfortran.dg/coarray_lib_alloc_4.f90: Fix for 32-bits.
+
 2016-12-01  Jakub Jelinek  <jakub@redhat.com>
 
 	PR debug/78587
Index: gcc/testsuite/gfortran.dg/coarray_lib_alloc_4.f90
===================================================================
--- gcc/testsuite/gfortran.dg/coarray_lib_alloc_4.f90	(Revision 243100)
+++ gcc/testsuite/gfortran.dg/coarray_lib_alloc_4.f90	(Arbeitskopie)
@@ -38,7 +38,7 @@
 end
 
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_is_present \\(xx\\.token, 2 - \\(integer\\(kind=4\\)\\) xx\\.dim\\\[0\\\]\\.lbound, &caf_ref\\.\[0-9\]+\\)|_gfortran_caf_is_present \\(xx\\.token, 2 - xx\\.dim\\\[0\\\]\\.lbound, &caf_ref\\.\[0-9\]+\\)" 10 "original" } }
-! { dg-final { scan-tree-dump-times "_gfortran_caf_register \\(72, 1, &xx\\.token, \\(void \\*\\) &xx, 0B, 0B, 0\\)" 1 "original" } }
+! { dg-final { scan-tree-dump-times "_gfortran_caf_register \\(\[0-9\]+, 1, &xx\\.token, \\(void \\*\\) &xx, 0B, 0B, 0\\)" 1 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_register \\(\[0-9\]+, 7" 2 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_register \\(\[0-9\]+, 8" 2 "original" } }
 ! { dg-final { scan-tree-dump-times "_gfortran_caf_deregister \\(&xx\\.token, 0, 0B, 0B, 0\\)" 1 "original" } }