From patchwork Sun Feb 11 17:13:35 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andre Vehreschild X-Patchwork-Id: 871788 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-473035-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="Y7gIrpbi"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3zfb4P1Z0bz9t5c for ; Mon, 12 Feb 2018 04:13:54 +1100 (AEDT) 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:subject:message-id:mime-version:content-type; q=dns; s= default; b=fUN5X9TKOvt8BIXOiSQ1FqFgKOx+PfV3d0r/220nuee5LWszDSBfw o4xnHSmWjcoSXhaKmg/HkKQy93UIWCZ7LtSTuUlzFUJ7cnjs0g0z86s5+UnYtbal fTDw4NrxC/5E9vzvCNH5wNPGqSVSLRpfsaVu2j5PpwlwceqDOcsAT8= 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:subject:message-id:mime-version:content-type; s= default; bh=4n7EhReAtvgBaXMbsaF0CSmDwzw=; b=Y7gIrpbixpZll+UUYxQr oP6Vtzf0lTYiY2H0dGWbSOPWhv3EdWcCZlvFdH2odl6vkXWf+mq89kpBtKiv4GVt 9fCD8Hj6irpx0jcacGbvlstKHbk+IL942WG9oAmsBNuMfQtZ7c7tuzpv6P7tETEK CJatYvG6omoFfIKzXGNvuos= Received: (qmail 15916 invoked by alias); 11 Feb 2018 17:13:43 -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 15886 invoked by uid 89); 11 Feb 2018 17:13:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.0 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=images X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 11 Feb 2018 17:13:40 +0000 Received: from vepi2 ([92.76.207.44]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MgKoE-1f8USc2UC6-00NghG; Sun, 11 Feb 2018 18:13:36 +0100 Date: Sun, 11 Feb 2018 18:13:35 +0100 From: Andre Vehreschild To: GCC-Patches-ML , GCC-Fortran-ML Subject: [Fortran, patch, coarray, v1] Fix a coarray issue and some documentation Message-ID: <20180211181335.2fb34a72@vepi2> MIME-Version: 1.0 X-UI-Out-Filterresults: notjunk:1; V01:K0:W1GW+8tCRYw=:ZGR+5IpfuhS6TotmpxB85Q mzPDeQv19u+bm5UcTHcRoeAaPZPdDE1oIE6EWIt6/+96YEBOm8M/Gk7qnDfLh0+A8dcgdAhTj 9m+h2LHA4nCKXfamcPEUajNxmjrJLrt8gpQ4s2KtGZvTrjZXmRi/u5kRlt9GvIRVAAgrDMnES K7gFcTAM5fiXF/yyyjjy3MBJASJBkBPfiW/w4FxobBxjoTziEn47Uu+nSScZREXQBF01kivd0 JU8+fWLMjcYagVpeZywdwlrBlscTzEmPAdl444qUJRRSd4RyqHH9KedY20FplF3H3BiXV+W/D KJy/fpuuF77aaVQV6QP1c8+e2SRz4t2k06VKDWdodM26OHiYt3QC1ThbtBHQkBt2yyReJqx6Z jtFwbzFoNqoXPKADRY/Nw0AAmO9AJD5xZjIMqdLaDSz9SbxlLTXweJrR3hywFfNYako8MGdsf FuQNtxkI/25KaLqHQgltOTYnFEVSyGU274sC4IzPlMMktBdLItdaW3Jj4jZJh9B3Fmlm0d51B brYqSmTqJp3M9BIinTNaKCEgCa5zH53UYxdqwic3y6Jjz9/Eu3XAQSzdbrzwZEiKeZK7jfHWI sU3XtGuQPe9TY1ZGOAeDHy3nO5egZkZz6ZfZHpox/oPoaG32eR8nld0FCOKCsnKHw34yEhBJF q+Ttli16c79XGyhHp439ejuwRgRVMOVOM21Mlxi+es7GRWNZQQDVrEAWxUqrOf1S6WO4u5Ev7 J/V4nEIuv7NnD9+nGtQONl/5/sZidDovIg3e55cU7GSu3llmtU5qQxsqjVborPP7XDEn+D/kD +AGyKGSP0vKfbTvRV2gXfPYv59Uug== Hi all, attached patch fixes a small coarray issue on ultimate component coarrays. The coarray was registered with the caf-library as if it were an allocatable component in a derived type coarray, which is just wasting resources. An ultimate component coarray has to be treated like a regular coarray. The second chunk of the patch fixes that. The first chunk of the attached patch just fixes some typos and style I found while reading the help text for caf_register(). Those are so small that I did not want to add another patch for this, given that both parts of the patch are somehow related. Bootstrapped and regtested on x86_64-linux-gnu/f27. Ok for trunk? Regards, Andre diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index 11246696e18..9ffe6ade661 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -4453,8 +4453,8 @@ is not used then. On the contrary when @code{CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY} is specified, then the @var{token} needs to be registered by a previous call with regtype @code{CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY} and either the memory specified -in the @var{desc}'s data-ptr is registered or allocate when the data-ptr is -NULL. +in the @var{DESC}'s data-ptr is registered or allocate when the data-ptr is +@code{NULL}. @item @emph{Syntax}: @code{void caf_register (size_t size, caf_register_t type, caf_token_t *token, @@ -4468,24 +4468,24 @@ allocated; for lock types and event types, the number of elements. @item @var{token} @tab intent(out) An opaque pointer identifying the coarray. @item @var{desc} @tab intent(inout) The (pseudo) array descriptor. @item @var{stat} @tab intent(out) For allocatable coarrays, stores the STAT=; -may be NULL +may be @code{NULL} @item @var{errmsg} @tab intent(out) When an error occurs, this will be set to -an error message; may be NULL +an error message; may be @code{NULL} @item @var{errmsg_len} @tab the buffer size of errmsg. @end multitable @item @emph{NOTES} -Nonalloatable coarrays have to be registered prior use from remote images. +Nonallocatable coarrays have to be registered prior use from remote images. In order to guarantee this, they have to be registered before the main program. This can be achieved by creating constructor functions. That is what -GCC does such that also nonallocatable coarrays the memory is allocated and no -static memory is used. The token permits to identify the coarray; to the +GCC does such that also for nonallocatable coarrays the memory is allocated and +no static memory is used. The token permits to identify the coarray; to the processor, the token is a nonaliasing pointer. The library can, for instance, store the base address of the coarray in the token, some handle or a more complicated struct. The library may also store the array descriptor @var{DESC} when its rank is non-zero. -For lock types, the value shall only used for checking the allocation +For lock types, the value shall only be used for checking the allocation status. Note that for critical blocks, the locking is only required on one image; in the locking statement, the processor shall always pass an image index of one for critical-block lock variables diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index d8b4381251e..4ffda26ca7d 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -8747,15 +8747,17 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl, cmp_has_alloc_comps = false; } - if (flag_coarray == GFC_FCOARRAY_LIB - && (caf_in_coarray (caf_mode) || c->attr.codimension)) + if (flag_coarray == GFC_FCOARRAY_LIB && caf_in_coarray (caf_mode)) { - /* Register the component with the coarray library. */ + /* Register a component of a derived type coarray with the + coarray library. Do not register ultimate component + coarrays here. They are treated like regular coarrays and + are either allocated on all images or on none. */ tree token; comp = fold_build3_loc (input_location, COMPONENT_REF, ctype, decl, cdecl, NULL_TREE); - if (c->attr.dimension || c->attr.codimension) + if (c->attr.dimension) { /* Set the dtype, because caf_register needs it. */ gfc_add_modify (&fnblock, gfc_conv_descriptor_dtype (comp),