From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31694 invoked by alias); 28 Jul 2016 09:55:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29204 invoked by uid 89); 28 Jul 2016 09:55:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*r:4.84, concats, H*Ad:U*cesar, H*r:esmtps X-HELO: outpost19.zedat.fu-berlin.de Received: from outpost19.zedat.fu-berlin.de (HELO outpost19.zedat.fu-berlin.de) (130.133.4.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 28 Jul 2016 09:55:46 +0000 Received: from relay1.zedat.fu-berlin.de ([130.133.4.67]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1bSi2Z-002gUE-BE>; Thu, 28 Jul 2016 11:55:43 +0200 Received: from mx.physik.fu-berlin.de ([160.45.64.218]) by relay1.zedat.fu-berlin.de (Exim 4.85) with esmtps (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id <1bSi2Z-0007hU-7p>; Thu, 28 Jul 2016 11:55:43 +0200 Received: from login2.physik.fu-berlin.de ([160.45.66.208]) by mx.physik.fu-berlin.de with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1bSi2T-0007g5-7W; Thu, 28 Jul 2016 11:55:37 +0200 Received: from tburnus by login2.physik.fu-berlin.de with local (Exim 4.84 #3 (Debian)) id 1bSi2T-0002tZ-5v; Thu, 28 Jul 2016 11:55:37 +0200 Date: Thu, 28 Jul 2016 09:55:00 -0000 From: Tobias Burnus To: Cesar Philippidis , gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, Jakub Jelinek Subject: Re: [PATCH] OpenACC routines in fortran modules Message-ID: <20160728095537.GB17012@physik.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5776D55A.4030002@codesourcery.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-07/txt/msg01845.txt.bz2 Cesar Philippidis wrote: > It turns out that the acc routine parallelism isn't being recorded in > fortran .mod files. This is a problem because then the ME can't validate > if a routine has compatible parallelism with the call site. Nothing against saving such information in .mod files. However, I wonder whether it can happen that one places such an 'acc routine' outside of a module in one file - and still accesses it from another file. In the simple non-ACC case, one can have: !----- one.f90 ---- subroutine foo() print *, "abc" end subroutine foo !---- two.f90 --- program example call foo() end program example where "foo()" is torn in without any information about it (except that it is a subroutine, does not require an explicit interface, and takes no arguments). I don't know whether the ACC spec requires an explicit interface in that case (i.e. for acc routines); I bet it does - or at least should. In that case, something like the following would be valid - and should be supported as well. (I don't know whether it currently is.) !----- one.f90 ---- subroutine foo() !$acc routine gang .... ! something end subroutine foo !---- two.f90 --- program example INTERFACE subroutine foo() !$acc routine gang ! Nothing here end subroutine foo END INTERFACE call foo() end program example Namely, a replication of the declaration of the procedure, including the "acc routine", in the 'interface'. (If one concats the two files, I would also expect an error with -fopenacc, if the "acc routine" doesn't match between "foo" and the "foo" in the "interface" block.) Otherwise: Have you checked whether an unmodified gfortran still accepts the .mod file written by the patched gfortran - and vice versa? Especially if -fopenacc is not used, backward compatibility of .mod files is a goal. (Even though we often have to bump the .mod version for major releases.) Cheers, Tobias