From patchwork Wed Nov 30 14:35:29 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Andre Vehreschild X-Patchwork-Id: 85877 Delivered-To: patch@linaro.org Received: by 10.140.20.101 with SMTP id 92csp255287qgi; Wed, 30 Nov 2016 06:36:05 -0800 (PST) X-Received: by 10.99.132.194 with SMTP id k185mr59698513pgd.171.1480516565079; Wed, 30 Nov 2016 06:36:05 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id p3si36172385pli.95.2016.11.30.06.36.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Nov 2016 06:36:05 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-443070-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-443070-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-443070-patch=linaro.org@gcc.gnu.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; q=dns; s=default; b=QIBVdHPo3QAXJqqS Ug0OolMZ7rvHmUTiWGbvxoIJA7qq+gjyG2ntVJrW3fObIOSA/FObLMBsbXPSjdSK MGzcFOJQYYLtH0sMe/d15V3ViOFwsRSA2Wdbj8WuA9PGNFpIied21m+Rq4Ls6G0I Tmx+bRuiL4FT7jY6gzw07JlwqEo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type; s=default; bh=/TxxaoNK8fxCD544FQJgx0 D93eg=; b=sHUSHEvznLshW5Q4pXalVpNWkHeMVAwTBJxFX1ZfeYAoW2rCjw62q0 MAGfMmkGZXF26QhzF1QA7ZiJXN4Ik2qLzprEoM/zy18eFgtd2PSKr/wUvWjsW/wS +OWBdZzCRLGFI838zK/iwdLIFfUpsk5bu3Ocxper0LoFjklG8BvTA= Received: (qmail 121668 invoked by alias); 30 Nov 2016 14:35:46 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 121616 invoked by uid 89); 30 Nov 2016 14:35:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=paulrichardthomasgmailcom, paul.richard.thomas@gmail.com, dominiq, party X-Spam-User: qpsmtpd, 3 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Nov 2016 14:35:34 +0000 Received: from vepi2 ([92.76.205.227]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lngv5-1cdCvd1mG7-00hrxN; Wed, 30 Nov 2016 15:35:30 +0100 Date: Wed, 30 Nov 2016 15:35:29 +0100 From: Andre Vehreschild To: Janus Weil Cc: Paul Richard Thomas , GCC-Patches-ML , GCC-Fortran-ML Subject: Re: PING! [PATCH, Fortran, accaf, v1] Add caf-API-calls to asynchronously handle allocatable components in derived type coarrays. Message-ID: <20161130153529.54bb0740@vepi2> In-Reply-To: <20161130152246.03eec0fd@vepi2> References: <20161122204650.03893214@vepi2> <20161128193330.55c0802a@vepi2> <20161130143007.235e8c73@vepi2> <20161130152246.03eec0fd@vepi2> MIME-Version: 1.0 X-UI-Out-Filterresults: notjunk:1; V01:K0:fNhB45f8ebs=:POtch8Z/4tPaPgPjVJ9tRq pQ1CP3zN87EuxwL7f1MMu12qN94myIT68EaZ+6Pc972dqEHqhAwOXMcOKxD2wHuHj+jDbnWG4 2yJViFk7SOY6C4Rxy2Rz3E+uGteY4WH3YQlbvZTheypjNUr+qpUiyMz0b0lWQ9BdgvEBOIcmK vk/Ly22PQDyUNKuawNC473yecHK+66M5I0kveUSazf+RJdQnp3WL2gd2D2zddEtPlgoJkFniX diKXjmrGPcOEjxb85nfnuNQkr3XtfcIsLPoj37HWD+NY7Dsx2oiNDGQrueoZHfxJfPkF/WwYz 4lGgaNCTc4EXEkzb7gi8q0kkco0FkwVWXBLgiNXHvIC7MLKyY2XURBJ2yzC3Ayt/Y2wJPlvrv 0S8hUydsRhieQe9scMyLL5I3kPWgTEhZVUwlUFqLw8aYWw4S9L7goTkun2/pSXcLBqdAmBAoZ TZ0wjZpx3YVQzPeiSuY1/+Dyd7ZlGEmvBZB2Tmvolp8lYuDiNvsX1sksPGsM/Oa8XlTTFm15M G/oB6Z95GtwyNMIecSMgjEIqsGdX/jgaL74I6+EYOHWYPSBA53lwraCQQOm1vBZDHG29WSqlx RjI07Ry6Stc2HnjtvwGiWIr5llRQnMJADMCBtycm9o9bMdSrZVLVZXPwLjpE3kww1OtWqQ8hG gy9qGK+fvAvy9+eGaa2Ck/3n4xS6XNYV4hI50+QKe1DY5AFym0Q8uXyJtacI84kP3+GTF4yOM QCSjagXNBsqLBVBCscW53Immn12YPueHQMBSfFHCf2fJQeOrExDcu5G19Zw= 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 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 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 : > > > 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 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 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 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: