diff mbox

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

Message ID 20161201105535.23358a5a@vepi2
State New
Headers show

Commit Message

Andre Vehreschild Dec. 1, 2016, 9:55 a.m. UTC 
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
diff mbox

Patch

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" } }