This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fortran OpenMP 4.0 target support
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org
- Date: Wed, 18 Jun 2014 00:04:42 +0200
- Subject: Re: [PATCH] Fortran OpenMP 4.0 target support
- Authentication-results: sourceware.org; auth=none
- References: <20140617210347 dot GF31640 at tucnak dot redhat dot com> <53A0BA3A dot 9090500 at net-b dot de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Jun 17, 2014 at 11:59:22PM +0200, Tobias Burnus wrote:
> >This patch adds the target directives.
> >Tested both normally plus with target.c/splay-tree.c from
> >gomp-4_0-branch@203409 plus the attached patch against
> >target.c to implement the new to_pset map kind (5) and
> >allow handling of NULL. That patch will need to be forward
> >ported to whatever gomp-4_0-branch now has after this is merged
> >from trunk to that branch.
> >
> >Does this look reasonable to Fortran maintainers?
>
> Thanks for the patch! I browsed through the patch, and it looked good to me.
> (However, given that the patch has "48 files changed, 3342 insertions(+),
> 330 deletions(-)", I didn't check every line.)
>
> If I did the book keeping correctly, a patch for an alignment test case is
> still missing. As are the changes for some corner cases for which the OpenMP
> ARB has to provide some feedback. Any news from that side? Otherwise and
> aside of 4.9.1 backporting, it now looks pretty complete.
I think some work is needed in tree-nested.c, ideally write a testcase
that tests all the new OpenMP 4.0 clauses in contained functions with and
without non-local decls (and with local decls used by contained functions).
One of the omp-lang answers shows some work is needed on the UDRs too, in
particular that the combiner/initializer should not be resolved as part of
the UDR directive, but only when used in a reduction clause where not only
the typespec, but also rank/shape, pointer/allocatable etc. are known.
Some further restriction checking is probably needed + backing that with
testcases. And wait for further omp-lang/omp-f2003 feedback.
Jakub