From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66756 invoked by alias); 6 Nov 2015 20:18:17 -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 66741 invoked by uid 89); 6 Nov 2015 20:18:17 -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_LOW,SPF_PASS autolearn=ham version=3.3.2 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, 06 Nov 2015 20:18:16 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZunSf-0001CW-Mk from James_Norris@mentor.com ; Fri, 06 Nov 2015 12:18:13 -0800 Received: from [172.30.80.115] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Fri, 6 Nov 2015 12:18:13 -0800 Message-ID: <563D0B03.30406@codesourcery.com> Date: Fri, 06 Nov 2015 20:18:00 -0000 From: James Norris User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jakub Jelinek CC: Thomas Schwinge , GCC Patches Subject: Re: [OpenACC] declare directive References: <562FDBF8.1040105@mentor.com> <5638E164.5010207@codesourcery.com> <87611h1zi7.fsf@kepler.schwinge.homeip.net> <563CD07A.3000404@codesourcery.com> <20151106190352.GG5675@tucnak.redhat.com> <20151106192255.GH5675@tucnak.redhat.com> In-Reply-To: <20151106192255.GH5675@tucnak.redhat.com> X-TagToolbar-Keys: D20151106141811689 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-11/txt/msg00726.txt.bz2 Jakub, On 11/06/2015 01:22 PM, Jakub Jelinek wrote: > On Fri, Nov 06, 2015 at 08:03:52PM +0100, Jakub Jelinek wrote: >> What exactly do you want to achieve? Why do you record it >> in gimplify_omp_ctx, but then only look at it in gimplify_body? >> The way you abuse gimplify_omp_ctx for that is just too ugly. >> All the gimplification code expects that when you enter some OpenMP/OpenACC >> construct, you create new context if it needs one, then process the body >> of the construct, then pop it up. The declare_returns stuff >> violates all of this. Do you want to enqueue all the statements >> at the end of the body? Then just stick it into some gimple_seq >> outside of the gimplify_omp_ctx, and process in there. Or if you >> want to process it when leaving some construct, arrange for that. > If the unmap operation is supposed to sit where the corresponding variable > goes out of scope, supposedly you would need to find out in which bind > (gimplify_ctx (not omp!)) the variable is declared and arrange for the > statement to be added as a cleanup of that region. > If you queue everything to the end of function, I'm afraid with e.g. > void foo (void) > { > { > char buf[2048]; > #acc declare whatever(buf) > // ... > } > { > char buf2[2048]; > #acc declare whatever(buf2) > // ... > } > } > both vars will be assigned overlapping ranges and you might run into > trouble trying to map buf2 while buf is still mapped. > > Jakub Good point. Thank you again, Jim