From patchwork Fri Oct 31 10:42:07 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 405264 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 8C1EC14007D for ; Fri, 31 Oct 2014 21:42:56 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; q=dns; s=default; b=c1scegNs8S+YhFY7 6v+XwLq48qUJKVNPoTHMkiE7+qsaHuuvm3Ek9nNWbSsoAW86HjRbdiXtQkdYd9uD +cGx7CKVoJfVSLttWUz7ReRLgTHmdPJ7kQ93Kq605ZYHrMr9UWKXNAqC1nU9py85 AqjiYYHIhjwI1wx3/+7ELgO7ldI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=default; bh=AZQ3CPRUmZER3DvUsm24YL pXQks=; b=ROFLeKv8E5PHM+p0CsYlf7zDkWomt5AEPWZlegs/fzWU9D0oWkn6zp z/9+VOBmae2FznowONsuF6D4RhJUMdWOOnJo6j6rMI2UOrpvBdov602k3iurLIGO unIsvTmU85kJkwET08U9WJW31Ty8QKkTIDA89hkJQUbxfx6IgNpCc= Received: (qmail 8954 invoked by alias); 31 Oct 2014 10:42:39 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 8797 invoked by uid 89); 31 Oct 2014 10:42:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 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 ESMTP; Fri, 31 Oct 2014 10:42:35 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1Xk9f4-0001T2-AH from Thomas_Schwinge@mentor.com ; Fri, 31 Oct 2014 03:42:30 -0700 Received: from feldtkeller.schwinge.homeip.net (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.181.6; Fri, 31 Oct 2014 10:42:29 +0000 From: Thomas Schwinge To: CC: , Tobias Burnus , Cesar Philippidis , James Norris , Jakub Jelinek Subject: Re: [gomp4] OpenACC acc_on_device In-Reply-To: <87k350n6zl.fsf@schwinge.name> References: <5418D6B6.40801@codesourcery.com> <20140917084411.GA12930@physik.fu-berlin.de> <20140917084954.GB17454@tucnak.redhat.com> <87k350n6zl.fsf@schwinge.name> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/24.3.1 (i586-pc-linux-gnu) Date: Fri, 31 Oct 2014 11:42:07 +0100 Message-ID: <87lhnwed1c.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Hi! On Thu, 18 Sep 2014 20:01:02 +0200, I wrote: > Here is my OpenACC acc_on_device patch, in a more complete form, with > test cases and all that. > > On Wed, 17 Sep 2014 10:49:54 +0200, Jakub Jelinek wrote: > > On Wed, Sep 17, 2014 at 10:44:12AM +0200, Tobias Burnus wrote: > > > Cesar Philippidis wrote: > > > > The patch introduces the following OpenACC/PTX-specific built-ins: > > > ... > > > > > > It is not completely clear how they are supposed to get used. Should the > > > user call them directly in some cases? Or are they only used internally? > > > > > > acc_on_device sounds like a function which would be in C/C++ made available > > > to the user via #define acc_on_device __builtin_acc_on_device. > > > > And not just providing acc_on_device prototype in some header? > > Yes, just a prototype. And next to DEF_GOACC_BUILTIN (configured the > same as DEF_GOMP_BUILTIN), I add a new DEF_GOACC_BUILTIN_COMPILER that is > configured to always provide the __builtin_[...] variant, but the > un-prefixed [...] only if -fopenacc is in effect. Does that look > alright? > > > Without > > looking at the OpenACC standard, it sounds like this function could be > > similar to omp_is_initial_device, so can and should be handled supposedly > > similarly. > > I think we've been talking about this at the Cauldron, where you agreed > that omp_is_initial_device should also be implemented as a builtin. (Or > am I confusing things?) > > > > However, the rest looks as if it should rather be an internal function > > > instead of a builtin. Or should the user really ever call the builtin > > > directly? > > > > GOMP_* functions are builtins and not internal functions too, all those > > functions are library functions, while the user typically doesn't call them > > directly, they still are implemented in the library. Internal functions are > > used for something that doesn't have a library implementation and is not > > something user can call directly. > > > > Regarding Fortran: Builtins aren't directly available to the user. You have to > > > wrap them into an intrinsic to make them available. If they have to be made > > > available via a module (e.g. via "module acc) - you have to create a virtual > > > module, which provides the intrinsic. If you don't want to convert the whole > > > module, you could create an auxiliar module (e.g. acc_internal_) which provides > > > only those bits - and then include it ("use,intrinsic :: ...") it in the > > > main module - written in normal Fortran. > > This I have not yet addressed -- please see the TODO comments in the > gcc/fortran/ files as well as Fortran test cases. > > > For the user callable fortran functions, for OpenMP libgomp just provides > > *_ entrypoints to * functions. Perhaps acc_on_device_ could be provided > > too. > > This is what I had done already. > > Does that patch look good? (With the Fortran things still to be > addressed.) (Checked in, back then, to gomp-4_0-branch in r215506.) > gcc/testsuite/ > * c-c++-common/goacc/acc_on_device-1.c: New file. > * c-c++-common/goacc/acc_on_device-2.c: Likewise. > * c-c++-common/goacc/acc_on_device-2-off.c: Likewise. Here is a patch, checked in to gomp-4_0-branch in r216953, to make acc_on_device-1.c C-only (implicitly declared functions are only "supported" in C), and make the others actually fit for C++ -- and XFAIL the C++ case. How to resolve that one? commit b1a009fdf340acf1840c1b6c9022be69a8f0a661 Author: tschwinge Date: Fri Oct 31 10:39:44 2014 +0000 Make acc_on_device test cases fit for C++. gcc/testsuite/ * c-c++-common/goacc/acc_on_device-1.c: Move... * gcc.dg/goacc/acc_on_device-1.c: ... here. (dg-additional-options): Add -std=c89. * c-c++-common/goacc/acc_on_device-2-off.c: Extend for C++. * c-c++-common/goacc/acc_on_device-2.c: Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@216953 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/testsuite/ChangeLog.gomp | 8 ++++++++ gcc/testsuite/c-c++-common/goacc/acc_on_device-2-off.c | 10 +++++++++- gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c | 16 ++++++++++++++-- .../{c-c++-common => gcc.dg}/goacc/acc_on_device-1.c | 2 +- 4 files changed, 32 insertions(+), 4 deletions(-) Grüße, Thomas diff --git gcc/testsuite/ChangeLog.gomp gcc/testsuite/ChangeLog.gomp index 10232bc..2489b39 100644 --- gcc/testsuite/ChangeLog.gomp +++ gcc/testsuite/ChangeLog.gomp @@ -1,3 +1,11 @@ +2014-10-30 Thomas Schwinge + + * c-c++-common/goacc/acc_on_device-1.c: Move... + * gcc.dg/goacc/acc_on_device-1.c: ... here. + (dg-additional-options): Add -std=c89. + * c-c++-common/goacc/acc_on_device-2-off.c: Extend for C++. + * c-c++-common/goacc/acc_on_device-2.c: Likewise. + 2014-10-20 Thomas Schwinge * gcc.dg/goacc/sb-1.c: Move file... diff --git gcc/testsuite/c-c++-common/goacc/acc_on_device-2-off.c gcc/testsuite/c-c++-common/goacc/acc_on_device-2-off.c index ddc43ab..25d21ad 100644 --- gcc/testsuite/c-c++-common/goacc/acc_on_device-2-off.c +++ gcc/testsuite/c-c++-common/goacc/acc_on_device-2-off.c @@ -1,13 +1,21 @@ /* Have to enable optimizations, as otherwise builtins won't be expanded. */ /* { dg-additional-options "-O -fdump-rtl-expand -fno-openacc" } */ +#if __cplusplus +extern "C" { +#endif + typedef enum acc_device_t { acc_device_X = 123 } acc_device_t; extern int acc_on_device (acc_device_t); +#if __cplusplus +} +#endif + int f (void) { - const int dev = acc_device_X; + const acc_device_t dev = acc_device_X; return acc_on_device (dev); } diff --git gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c index 65b4ae6..d5389a9 100644 --- gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c +++ gcc/testsuite/c-c++-common/goacc/acc_on_device-2.c @@ -1,17 +1,29 @@ /* Have to enable optimizations, as otherwise builtins won't be expanded. */ /* { dg-additional-options "-O -fdump-rtl-expand" } */ +#if __cplusplus +extern "C" { +#endif + typedef enum acc_device_t { acc_device_X = 123 } acc_device_t; extern int acc_on_device (acc_device_t); +#if __cplusplus +} +#endif + int f (void) { - const int dev = acc_device_X; + const acc_device_t dev = acc_device_X; return acc_on_device (dev); } /* With -fopenacc, we're expecting the builtin to be expanded, so no calls. - { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device" 0 "expand" } } */ + TODO: in C++, even under extern "C", the use of enum for acc_device_t + perturbs expansion as a builtin, which expects an int parameter. It's fine + when changing acc_device_t to plain int, but that's not what we're doing in + . + { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device" 0 "expand" { xfail c++ } } } */ /* { dg-final { cleanup-rtl-dump "expand" } } */ diff --git gcc/testsuite/c-c++-common/goacc/acc_on_device-1.c gcc/testsuite/gcc.dg/goacc/acc_on_device-1.c similarity index 82% rename from gcc/testsuite/c-c++-common/goacc/acc_on_device-1.c rename to gcc/testsuite/gcc.dg/goacc/acc_on_device-1.c index e606b88..1a0276e 100644 --- gcc/testsuite/c-c++-common/goacc/acc_on_device-1.c +++ gcc/testsuite/gcc.dg/goacc/acc_on_device-1.c @@ -1,5 +1,5 @@ /* Have to enable optimizations, as otherwise builtins won't be expanded. */ -/* { dg-additional-options "-O -fdump-rtl-expand -Wno-implicit-function-declaration" } */ +/* { dg-additional-options "-O -fdump-rtl-expand -std=c89 -Wno-implicit-function-declaration" } */ int f (void)