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 <ja...@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 <ve...@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.tho...@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 <ve...@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 <ve...@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
