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 2A6053858D3C for ; Fri, 2 Jun 2023 21:04:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A6053858D3C 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.17.1/8.17.1) with ESMTPS id 352L47EH045265 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 2 Jun 2023 14:04:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 352L455N045262; Fri, 2 Jun 2023 14:04:05 -0700 (PDT) (envelope-from sgk) Date: Fri, 2 Jun 2023 14:04:05 -0700 From: Steve Kargl To: Paul Richard Thomas Cc: Paul Richard Thomas via Fortran , "Jorge D'Elia" , "Jorge D'Elia" Subject: Re: A doubt about IMPORT and SELECT TYPE Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <6b48bc0f-043f-4635-abaf-bac09d67323b.1685712510891@community.intel.com> <1260414420.3647.1685715134551.JavaMail.zimbra@intec.unl.edu.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: Oh, I'm not asking you or any of the other regular contributors to gfortran to pick up my WIP patch and finish the last 5%. Now, lurkers on the mailing list, who have always wanted to give back, well I'm more than willing to help explain the patch and what I think needs to be done if they are so inclined to get their hands dirty. IMPORT is an interesting construct. Originally, all entities are blocked from host assocation into an INTERFACE, so J3 invented IMPORT to allow one to cherry pick entities from the host. gfortran's implementation is fairly straightforward. In F2018, J3 extended IMPORT to block host-association in for example a contained subprogram or BLOCK construct. This seems like a logical and good thing; except this is the complete opposite of its original use. Undoing/revising gfortran'sr original implemenation of IMPORT is a bit more challenging. -- steve On Fri, Jun 02, 2023 at 09:14:01PM +0100, Paul Richard Thomas wrote: > Hi Steve, > > As noted in the previous email :-), although I didn't mention the partially > cooked patch. > > One day, once F2003 is sorted, I might turn to F2008/18! > > Cheers > > Paul > > > On Fri, 2 Jun 2023, 16:27 Steve Kargl via Fortran, > wrote: > > > On Fri, Jun 02, 2023 at 03:53:44PM +0100, Paul Richard Thomas via Fortran > > wrote: > > > Hi Jorge, > > > > > > As I posted in the Intel Community, the error generated by gfortran > > > (and nagfor) is consistent with the F2003 constraint: C1210 (R1209) > > > The IMPORT statement is allowed only in an interface-body. > > > > > > Could you please raise a problem report in gcc Bugzilla? > > > > > > > There already is a PR about IMPORT. See > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106035 > > > > There is a patch that is 95-ish% complete. The last > > 5% is the hard part, which it seems no one has had > > time or ideas on how to finish the patch. > > > > -- > > Steve > > -- Steve