From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28558 invoked by alias); 13 Jul 2015 17:11:40 -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 28542 invoked by uid 89); 13 Jul 2015 17:11:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_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; Mon, 13 Jul 2015 17:11:38 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 48A4E223 for ; Mon, 13 Jul 2015 17:11:37 +0000 (UTC) Received: from reynosa.quesejoda.com (vpn-48-188.rdu2.redhat.com [10.10.48.188]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6DHBaOK012448; Mon, 13 Jul 2015 13:11:36 -0400 Message-ID: <55A3F147.10301@redhat.com> Date: Mon, 13 Jul 2015 17:11:00 -0000 From: Aldy Hernandez 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: gcc-patches Subject: Re: [gomp4.1] depend(sink) and depend(source) parsing for C References: <559EBC6C.70109@redhat.com> <20150709185315.GY10247@tucnak.redhat.com> <55A008FF.10609@redhat.com> <55A161F8.8010800@redhat.com> <20150713135618.GQ1788@tucnak.redhat.com> In-Reply-To: <20150713135618.GQ1788@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg01071.txt.bz2 On 07/13/2015 06:56 AM, Jakub Jelinek wrote: > On Sat, Jul 11, 2015 at 11:35:36AM -0700, Aldy Hernandez wrote: > On the C++ FE side, please also try a testcase in g++.dg/gomp/ where > the ordered(n) loop with #pragma omp ordered depend({source,sink}) will be > in a template, to make sure pt.c does the right thing with it. I assume you mean something like: void bar (int, int, int); template T baz (T arg) { int i, j, k; #pragma omp parallel for ordered(2) for (i=0; i < 100; ++i) for (j=0; j < 100; ++j) { #pragma omp ordered depend(sink:i-3,j) bar (i, j, 0); } return arg; } int main() { return baz(5); } ?? Also, was this supposed to work?: template int foo() { int i, j, k; #pragma omp parallel for ordered(N) for (i=0; i < 100; ++i) for (j=0; j < 100; ++j) { extern void bark(); bark(); } } The above was broken before I arrived. And if this last example is supposed to work, I should probably address the same thing for sink offsets. > If you want to spend time on something still in the FE, it would be nice to > resolve the C++ iteration var issue (i.e. increase OMP_FOR number of > arguments, so that it could have yet another (optional) vector, say > OMP_FOR_ORIG_DECLS. If that vector would be NULL, the gimplifier would > assume that all the decls in OMP_FOR_INIT are the ones present in the > source, if it would be present, you'd use them for the variable checking > instead of the ones from OMP_FOR_INIT (but, replace them with the > decls from OMP_FOR_INIT after the checking). > > There is another issue - if some iterator var has pointer type, supposedly > we want somewhere in the FEs already multiply it by the size of what they > point to (and convert to sizetype). For C FE, it can be done already during > parsing, we should know the type of the iterator var already at that point, > for C++ FE it needs to be done only in finish_omp_clauses if > !processing_template_decl, because in templates we might not know the type. Sure. As follow-ups? Aldy