| Message ID | 20161130153529.54bb0740@vepi2 |
|---|---|
| State | New |
| Headers | show |
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
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: