From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54492 invoked by alias); 30 Oct 2015 15:02:27 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 54473 invoked by uid 89); 30 Oct 2015 15:02:26 -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,RCVD_IN_DNSWL_LOW,SPF_PASS 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, 30 Oct 2015 15:02:16 +0000 Received: from svr-orw-fem-03.mgc.mentorg.com ([147.34.97.39]) by relay1.mentorg.com with esmtp id 1ZsBC0-00025r-VL from Cesar_Philippidis@mentor.com ; Fri, 30 Oct 2015 08:02:13 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-fem-03.mgc.mentorg.com (147.34.97.39) with Microsoft SMTP Server id 14.3.224.2; Fri, 30 Oct 2015 08:02:12 -0700 Subject: Re: more accurate omp in fortran To: Jakub Jelinek References: <5628FEFF.50809@codesourcery.com> <20151030144727.GC478@tucnak.redhat.com> CC: Fortran List , "gcc-patches@gcc.gnu.org" From: Cesar Philippidis Message-ID: <56338674.3060608@codesourcery.com> Date: Fri, 30 Oct 2015 15:02:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151030144727.GC478@tucnak.redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00182.txt.bz2 On 10/30/2015 07:47 AM, Jakub Jelinek wrote: > On Thu, Oct 22, 2015 at 08:21:35AM -0700, Cesar Philippidis wrote: >> diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h >> index b2894cc..93adb7b 100644 >> --- a/gcc/fortran/gfortran.h >> +++ b/gcc/fortran/gfortran.h >> @@ -1123,6 +1123,7 @@ typedef struct gfc_omp_namelist >> } u; >> struct gfc_omp_namelist_udr *udr; >> struct gfc_omp_namelist *next; >> + locus where; >> } >> gfc_omp_namelist; >> >> diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c >> index 3c12d8e..56a95d4 100644 >> --- a/gcc/fortran/openmp.c >> +++ b/gcc/fortran/openmp.c >> @@ -244,6 +244,7 @@ gfc_match_omp_variable_list (const char *str, gfc_omp_namelist **list, >> } >> tail->sym = sym; >> tail->expr = expr; >> + tail->where = cur_loc; >> goto next_item; >> case MATCH_NO: >> break; >> @@ -278,6 +279,7 @@ gfc_match_omp_variable_list (const char *str, gfc_omp_namelist **list, >> tail = tail->next; >> } >> tail->sym = sym; >> + tail->where = cur_loc; >> } >> >> next_item: > > The above is fine. Thanks. I'll apply this change separately. >> @@ -2832,36 +2834,47 @@ resolve_omp_udr_clause (gfc_omp_namelist *n, gfc_namespace *ns, >> return copy; >> } >> >> -/* Returns true if clause in list 'list' is compatible with any of >> - of the clauses in lists [0..list-1]. E.g., a reduction variable may >> - appear in both reduction and private clauses, so this function >> - will return true in this case. */ >> +/* Check if a variable appears in multiple clauses. */ >> >> -static bool >> -oacc_compatible_clauses (gfc_omp_clauses *clauses, int list, >> - gfc_symbol *sym, bool openacc) >> +static void >> +resolve_omp_duplicate_list (gfc_omp_namelist *clause_list, bool openacc, >> + int list) >> { >> gfc_omp_namelist *n; >> + const char *error_msg = "Symbol %qs present on multiple clauses at %L"; > > Please don't do this, I'm afraid this breaks translations. > Also, can you explain why all the mess with OMP_LIST_REDUCTION && openacc? > That clearly looks misplaced to me. > If one list item may be in at most one reduction clause, but may be in > any other clause too, then it is the same case as e.g. OpenMP > OMP_LIST_ALIGNED case, so you should instead just: > && (list != OMP_LIST_REDUCTION || !openacc) > to the for (list = 0; list < OMP_LIST_NUM; list++) loop, and handle > OMP_LIST_REDUCTION specially, similarly how OMP_LIST_ALIGNED is handled, > just guarded with if (openacc). That's a good idea, thanks. Reduction variables may appear in multiple clauses in openacc because you have have reductions on kernels and parallel constructs. And the same reduction variable may be associated with a data clause. Cesar