This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [gomp4, openacc-1_0-branch] Re: OpenACC branch
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: Evgeny Gavrin <e dot gavrin at samsung dot com>, "'Viacheslav Garbuzov'" <v dot garbuzov at samsung dot com>, i dot usmanov at samsung dot com, "'Dmitri Botcharnikov'" <dmitry dot b at samsung dot com>, gcc at gcc dot gnu dot org, iverbin at gmail dot com, michael dot v dot zolotukhin at gmail dot com, triegel at redhat dot com, kirill dot yukhin at gmail dot com, nathan at codesourcery dot com
- Date: Mon, 30 Sep 2013 09:30:47 +0200
- Subject: Re: [gomp4, openacc-1_0-branch] Re: OpenACC branch
- Authentication-results: sourceware.org; auth=none
- References: <008801cebae4$f2842760$d78c7620$%gavrin at samsung dot com> <874n93waf0 dot fsf at kepler dot schwinge dot homeip dot net>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Sep 30, 2013 at 12:05:55AM +0200, Thomas Schwinge wrote:
> Is my understanding correct that the GCC policy regarding extensions such
> as support for OpenACC or OpenMP 4 is: first develop and polish this on a
> branch (such as openacc-1_0-branch or gomp-4_0-branch), and once
> *everything* of the respective standard has been implemented, the
> development branch is then merged into mainline (closing it at the same
> time), instead of committing individual sub-features (such as support for
> only »#pragme acc parallel« but not yet covering the whole respective
> standard) directly to trunk? The issue with the latter, I assume, is
> that such half-finished implementations in trunk might delay/disturb GCC
> releases.
My actual plan with gomp-4_0-branch is to merge the branch to the trunk
in a week or two. The missing parts of OpenMP 4.0 support right now are:
1) Fortran support - didn't have spare cycles for it yet, but I think
initially we can just support C/C++ OpenMP 4.0 and Fortran OpenMP 3.1,
and as time permits add the missing Fortran support
2) OMP_PLACES/affinity - library only side, plan to work on that this week
3) target support ICV handling - library side only, plan to work on that this week
4) elemental functions - this is currently parsed, but ignored, I'd prefer
this being developed on the gomp-4_0-branch after the branch is merged
with trunk, then committed
5) offloading - once 3) is supported, we should be hopefully OpenMP 4.0
compliant with regards to target* constructs, just always do host
fallback, further development of actual offloading should continue
on gomp-4_0-branch
Jakub