This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] OpenACC fortran front end
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Julian Brown <julian at codesourcery dot com>
- Cc: Cesar Philippidis <cesar at codesourcery dot com>, Tobias Burnus <burnus at net-b dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, fortran at gcc dot gnu dot org, Ilmir Usmanov <i dot usmanov at samsung dot com>
- Date: Tue, 11 Nov 2014 17:51:01 +0100
- Subject: Re: [patch] OpenACC fortran front end
- Authentication-results: sourceware.org; auth=none
- References: <545BF570 dot 8070508 at codesourcery dot com> <54613773 dot 50109 at net-b dot de> <54613F9A dot 90907 at codesourcery dot com> <20141111071029 dot GV5026 at tucnak dot redhat dot com> <20141111145220 dot 6900a0b2 at octopus>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Nov 11, 2014 at 02:52:20PM +0000, Julian Brown wrote:
> On Tue, 11 Nov 2014 08:10:29 +0100
> Jakub Jelinek <jakub@redhat.com> wrote:
>
> > On Mon, Nov 10, 2014 at 02:43:38PM -0800, Cesar Philippidis wrote:
> > > >> I'll post a separate patch with the fortran tests later. If
> > > >> anyone wants to test this patch, please use gomp-4_0-branch
> > > >> instead. You don't need a CUDA accelerator to use
> > > >> OpenACC, and some of the runtime tests will fail because that
> > > >> branch doesn't include the nvptx backend.
> > > > Now that the first series of PTX target patches have been
> > > > committed: I assume it is still true that nvptx doesn't work
> > > > because the libgomp bits aren't in yes, isn't it?
> > >
> > > That's correct. The nvptx backend also depends on the offloading
> > > changes that a team from Intel is working on for the MIC target.
> > > But Julian should be posting the libgomp patches tomorrow, I think,
> > > since his changes are somewhat self-contained.
> >
> > For the middle-end and libgomp changes, can you talk to the Intel
> > folks to update their git branch to latest trunk (so that you have
> > the nvptx bits in there) and send middle-end and libgomp diffs
> > against that? As far as I remember, most of the changes from the
> > branch are now approved, they are just waiting for review of the LTO
> > related changes in the middle-end (please, correct me if I've missed
> > something).
>
> We've been preparing new patches against trunk for the libgomp and
> middle-end bits: I've now posted the former, and the latter are on
> their way soon, I believe. The middle-end bits are also present on the
> gomp-4_0-branch SVN branch (likewise, the libgomp pieces), and I
> believe we're planning to merge the PTX bits there also now they've
> been committed to trunk.
>
> Is it really worthwhile merging our patches to yet another branch at
> this stage?
The point is that the kyukhin/gomp4-offload branch is mostly reviewed now
(waiting for Richard and/or Honza now to review the last LTO bits)
and your patches have huge overlap with that, so sending patches against
trunk that implement the same thing would mean reviewing the same bits
again, and worse if there are conflicts between the two patchsets, if
both patchsets were to be approved, one couldn't be committed anyway.
Jakub