From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id 3D6D2384F3C7 for ; Thu, 12 Jan 2023 03:07:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3D6D2384F3C7 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.16.1/8.16.1) with ESMTPS id 30C37RxH022043 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 11 Jan 2023 19:07:27 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.16.1/8.16.1/Submit) id 30C37QNu022042 for fortran@gcc.gnu.org; Wed, 11 Jan 2023 19:07:26 -0800 (PST) (envelope-from sgk) Date: Wed, 11 Jan 2023 19:07:26 -0800 From: Steve Kargl To: Jerry DeLisle via Fortran Subject: Re: Error on left hand function reference Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <9fcade0f-a67e-35ba-e6d0-dc0f90b18d39@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fcade0f-a67e-35ba-e6d0-dc0f90b18d39@protonmail.com> X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Jan 12, 2023 at 02:31:12AM +0000, Jerry DeLisle via Fortran wrote: > Hi all, > > I spotted this today on the Fortran-Lang Discourse. > > It would not be setting precednce for us to allow an extension and turn > this into a warning with -std=gnu and an error of strict compliance is > wanted. > > https://fortran-lang.discourse.group/t/error-the-leftmost-part-ref-in-a-data-ref-cannot-be-a-function-reference/4990 > > I will create a PR and chase this one if concurrence here. > > Opinions? > gfortran's current behavior is standard conforming. Personally, I think this should not be implemented in gfortran. If you do scratch the itch, then please hide it behind some option such as -fallow-nonconforming-Fortran-leftmost-part-reference-function-component. Please, do not enable it under -std=gnu (which should be deprecated in favor of -std=f2018 and then -std=f2023). Putting it under -std=gnu would imply that it will be supported in future versions of gfortran and would need to support whatever is implemented now and whatever might get standardized in the future. I'll send end by noting that there are several unimplemented F2018 features and F2023 will be approved in the April-ish timeframe. -- Steve