On 11/07/2015 03:45 AM, Thomas Schwinge wrote: > Hi! > > On Fri, 6 Nov 2015 15:31:23 -0800, Cesar Philippidis <ce...@codesourcery.com> > wrote: >> I've applied this patch to gomp-4_0-branch which backports most of my >> front end changes from trunk. Note that I found a regression while >> testing, which is also present in trunk. It looks like >> kernels-acc-loop-reduction.c is failing because I'm incorrectly >> propagating the reduction variable to both to the kernels and loop >> constructs for combined 'acc kernels loop'. The problem here is that >> kernels don't support the reduction clause. I'll fix that next week. > > Always need to consider both what the specification allows -- and thus > what the front ends accept/refuse -- as well as what we might do > differently, internally in later processing stages. I have not analyzed > whether it makes sense to have the OMP_CLAUSE_REDUCTION of a combined > "kernels loop reduction([...])" construct be attached to the outer > OACC_KERNELS or inner OACC_LOOP, or duplicated for both. > > Tom, if you need a solution for that right now/want to restore the > previous behavior (attached to innter OACC_LOOP only), here's what you > should try: in gcc/c-family/c-omp.c:c_oacc_split_loop_clauses remove the > special handling for OMP_CLAUSE_REDUCTION, and move it to "Loop clauses" > section, and in
That should would work. > gcc/fortran/trans-openmp.c:gfc_trans_oacc_combined_directive I don't see > reduction clauses being handled, hmm, maybe the Fortran front end is > doing that differently? You're correct, reductions are being associated with kernels and parallel constructs. This is one area that needed more test cases, but things like 'acc parallel reduction(+:var) copy(var)' was broken because of the recent gimplifier changes, so I couldn't test for it. I was planning on fixing both problems (reductions and variable appearing in multiple clauses) after Nathan's firstprivate and default gimplifier changes landed in trunk. Cesar
