From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153]) by sourceware.org (Postfix) with ESMTPS id 04D953857C77; Fri, 2 Jul 2021 22:13:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 04D953857C77 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 9OFVbuG3iUlfosAx5714WVBguaLbZT469K+BWyQ6J/Sdq3aanMEkIEof9ossDIId12RhYED5S8 48kgjAO2YdkdbEVmvlDRAAdx7J3UkLBZ3+c7sWSst3/4a4IeJQjFeJV3a2bd2FovqeyRrQFq1d Z7mxTxgBLCvLdWczcs8X/9G2ha1/sgJyHIC1orSfVGv7XsH0Zqkxf5vFHhSECTI9KMcKb8ovRS O16jUHp3pb0sAZMOJEXn4L3KKCz07xx/D2+mF3B5VRyLwCjAG0nlELowImLpg1Nvv+iJ4uEAzM FaQ= X-IronPort-AV: E=Sophos;i="5.83,320,1616486400"; d="scan'208";a="65541212" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa1.mentor.iphmx.com with ESMTP; 02 Jul 2021 14:13:58 -0800 IronPort-SDR: JRQqWTxQCdL8VsUwtgaqxYsgyBjjYeKNAgUqXCZBnsIS5Agii/uueJkf1c6YdeyyofqADFg2JV V++LTL2jGqPYuVFUmFCx226ZC8f87C7vIdK2Akhac31ib6tg8xL+GfoxMT19ppi8QBC/P6JUNf dofD/NXk62AXzD+uJizZa9AGKzusGGQb0tIS4IKXZ0FGm8rqPvmfPY6ARK33wJpPxpctZa1lbQ 2qPh9rAI9SpwpwgwOo14cxluOVdvbCdjW9mzO7H43GvOxeUisEQa3SRNE64x3YFNTbN7ecgWGY Y0s= Subject: Re: [Patch] Fortran: Fix bind(C) character length checks To: Tobias Burnus , gcc-patches , fortran , Paul Richard Thomas References: <602673f7-ea8e-9e71-23cb-4989ed23e079@codesourcery.com> From: Sandra Loosemore Message-ID: <16bdad19-5548-f271-e7b2-997632bf29e1@codesourcery.com> Date: Fri, 2 Jul 2021 16:13:52 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <602673f7-ea8e-9e71-23cb-4989ed23e079@codesourcery.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ClientProxiedBy: svr-orw-mbx-01.mgc.mentorg.com (147.34.90.201) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, BODY_8BITS, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:14:01 -0000 On 7/1/21 11:08 AM, Tobias Burnus wrote: > Hi all, > > this patch came up when discussing Sandra's TS29113 patch internally. > There is presumably also some overlap with José's patches. > > This patch tries to rectify the BIND(C) CHARACTER handling on the > diagnostic side, only. That is: what to accept and what > to reject for which Fortran standard. > > > The rules are: > > * [F2003-F2018] Interoperable is character(len=1) >   → F2018, 18.3.1  Interoperability of intrinsic types >   (General, unchanged) > > * Fortran 2008: In some cases, const-length chars are >   permitted as well: >   → F2018, 18.3.4  Interoperability of scalar variables >   → F2018, 18.3.5  Interoperability of array variables >   → F2018, 18.3.6  Interoperability of procedures and procedure interfaces >  [= F2008, 15.3.{4,5,6} > For global vars with bind(C), 18.3.4 + 18.3.5 applies directly (TODO: > Add support, not in this patch) > For passed-by ref dummy arguments, 18.3.4 + 18.3.5 are referenced in > - F2008: R1229  proc-language-binding-spec is language-binding-spec >          C1255 (R1229) > - F2018, F2018, C1554 > > While it is not very clearly spelt out, I regard 'char parm[4]' > interoperable with 'character(len=4) :: a', 'character(len=2) :: b(2)' > and 'character(len=1) :: c(4)' for both global variables and for > dummy arguments. > > * Fortran 2018/TS29113:  Uses additionally CFI array descriptor >   - allocatable, pointer:  must be len=: >   - nonallocatable/nonpointer: len=* → implies array descriptor also >     for assumed-size/explicit-size/scalar arguments. >   - All which all passed by an array descriptor already without further >     restrictions: assumed-shape, assumed-rank, i.e. len= seems >     to be also fine > → 18.3.6 under item (5) bullet point 2 and 3 plus (6). > > > I hope I got the conditions right. I also fixed an issue with > character(len=5) :: str – the code in trans-expr.c did crash for > scalars  (decl.c did not check any constraints for arrays). > I believe the condition is wrong and for len= no descriptor > is used. > > Any comments, remarks? I gave this patch a try on my TS 29113 last night. Changing the error messages kind of screwed up my list of FAILs, but I did see that it also caught some invalid character arguments in interoperability/typecodes-scalar.f90 and interoperability/typecodes-scalar-ext.f90 (which are already broken by 2 other major gfortran bugs I still need to file PRs for). :-S I haven't tried to review the patch WRT correctness with the requirements of the standard yet, but I have a few nits about error messages.... > + /* F2018, 18.3.6 (6). */ > + if (!sym->ts.deferred) > + { > + gfc_error ("Allocatable and pointer character dummy " > + "argument %qs at %L must have deferred length " > + "as procedure %qs is BIND(C)", sym->name, > + &sym->declared_at, sym->ns->proc_name->name); > + retval = false; > + } This is the error the two aforementioned test cases started giving, but message is confusing and doesn't read well (it was a pointer dummy, not "allocatable and pointer"). Maybe just s/and/or/, or customize the message depending on which one it is? > + gfc_error ("Character dummy argument %qs at %L must be " > + "of constant length or assumed length, " > + "unless it has assumed-shape or assumed-rank, " > + "as procedure %qs has the BIND(C) attribute", > + sym->name, &sym->declared_at, > + sym->ns->proc_name->name); I don't think either "assumed-shape" or "assumed-rank" should be hyphenated in this context unless that exact hyphenation is a term of art in the Fortran standard or other technical documentation. In normal English, adjective phrases are usually only hyphenated when they appear immediately before the noun they modify; "assumed-shape array", but "an array with assumed shape". > + else if (!gfc_notify_std (GFC_STD_F2018, > + "Character dummy argument %qs at %L" > + " with nonconstant length as " > + "procedure %qs is BIND(C)", > + sym->name, &sym->declared_at, > + sym->ns->proc_name->name)) > + retval = false; > + } Elsewhere the convention seems to be to format strings split across multiple lines with a space at the end of each chunk rather than at the beginning. -Sandra