From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14042 invoked by alias); 30 Oct 2014 02:53:36 -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 14010 invoked by uid 89); 30 Oct 2014 02:53:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 30 Oct 2014 02:53:28 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9U2rPqh020655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 29 Oct 2014 22:53:25 -0400 Received: from [10.3.113.140] (ovpn-113-140.phx2.redhat.com [10.3.113.140]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9U2rPXd026588; Wed, 29 Oct 2014 22:53:25 -0400 Message-ID: <5451A824.7050505@redhat.com> Date: Thu, 30 Oct 2014 03:09:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Bernd Schmidt , GCC Patches Subject: Re: The nvptx port [10/11+] Target files References: <54451994.9070209@codesourcery.com> <54451D57.5050803@codesourcery.com> <5447F0E1.7080906@redhat.com> <544FAE8B.5010906@codesourcery.com> <545179C6.4030406@redhat.com> <54517E58.3030808@codesourcery.com> In-Reply-To: <54517E58.3030808@codesourcery.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg03161.txt.bz2 On 10/29/14 17:55, Bernd Schmidt wrote: > Thanks! I've pinged some of the preliminary patches that went unapproved > up to this point. Thanks. > > One leftover issue, discussed in the [0/11] mail - what amount of > documentation is appropriate for this, given that we don't want to > support using this as anything other than an offload compiler? Should I > still add all the standard invoke.texi/gccint.texi pieces? I'm still not sure here. nvptx is quite a bit different than anything we've done in the past and I'm not sure how much of the traditional stuff we want to document vs on the other end how much of the special stuff we want to document. I simply don't know. >> I notice that you've got some OpenMP bits (write_as_kernel). Are y'all >> doing any testing with OpenMP or is that an artifact of layering OpenACC >> on top of the OpenMP infrastructure? > > The distinction between .kernel and .func is really not to do with > either - only .kernels are callable from the host, and only .funcs are > callable from within ptx code. Ok. Thanks for clarifying. jeff