From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51671 invoked by alias); 28 Jul 2016 21:33:48 -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 51647 invoked by uid 89); 28 Jul 2016 21:33:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=preserved, treating, mandatory, Hx-languages-length:3612 X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 28 Jul 2016 21:33:37 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1bSsvu-00001I-Le from Cesar_Philippidis@mentor.com ; Thu, 28 Jul 2016 14:33:34 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Thu, 28 Jul 2016 14:33:34 -0700 Subject: Re: [PATCH] OpenACC routines in fortran modules To: Tobias Burnus , , , Jakub Jelinek References: <20160728095537.GB17012@physik.fu-berlin.de> From: Cesar Philippidis Message-ID: <579A7A2E.7030503@codesourcery.com> Date: Thu, 28 Jul 2016 21:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160728095537.GB17012@physik.fu-berlin.de> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-SW-Source: 2016-07/txt/msg01896.txt.bz2 On 07/28/2016 02:55 AM, Tobias Burnus wrote: > 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 Jakub and I discussed this issue a while ago. There were two major problems with treating calls to non-acc routines as errors. 1) What do we do about intrinsic procedures, and 2) how should builtin and libc/libm functions get handled? Jakub and I came to the conclusion that the linker should resolve those issues, hence this patch which teaches the lto wrapper to error when it encounters missing symbols. From a compiler standpoint, if the user does something like this !$acc parallel ... call foo() ... !$acc end parallel and if foo isn't marked as an acc routine, then the compiler will treat that function as having an implicit 'acc routine seq'. Note that trunk currently generates an error if the user tries apply an acc routine directive on an intrinsic routine. This patch teaches gfortran to accept acc routine directives on those procedures. However, note that those routines aren't automatically parallelized though, i.e. they are effectively implemented as 'acc routine seq'. > 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.) I tested this case and it works. There is, however, a problem with mismatched routine clauses. See PR72741 that Thomas filed recently. > 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.) I just tested this situation, and neither backward or forward compatible isn't preserved. Basically, this patch introduces a mandatory OACC_FUNCTION_ field inside the module file. Perhaps I should make that field optional. At least that way we'd maintain backwards compatibility. Is there something I can do to maintain forward compatibility? Cesar