Combined constructs' clause splitting (was: [gomp4] backport trunk FE changes)

Thomas Schwinge thomas@codesourcery.com
Sat Nov 7 11:45:00 GMT 2015


Hi!

On Fri, 6 Nov 2015 15:31:23 -0800, Cesar Philippidis <cesar@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
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?


Grüße
 Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20151107/af125e9f/attachment.sig>


More information about the Gcc-patches mailing list