First, pardon the long CC list.  You are, in my understanding, the people
who are interested in collaborating on the topics that are being prepared
on gomp-4_0-branch: "LTO" streaming, acceleration device offloading,
OpenMP target, OpenACC, nvptx backend -- and more?

As we've noticed, and he has just recently told me, Jakub currently is
totally occupied with getting the GCC 4.9 release in shape, and thus
can't spend any reasonable amount of time on reviewing/developing patches
for the gomp-4_0-branch topics.  He suggested that I "take over" the
branch, and he would chime in again, once his GCC 4.9 duties have calmed

Now, my experience of GCC of course is nowhere close to Jakub's, and even
though I'm learning a lot, it's not possible for me to provide patch
reviews with the same quality as he does.  On the other hand, I consider
gomp-4_0-branch to be a development branch, so I'm fine with people
committing stuff there that is not totally polished, as long as it
doesn't cause havoc to the existing code (as made evident by compiler
warnings during the GCC build as well as regressions in the testsuite).
There can be occasional exceptions to this, for example if a patch causes
a testsuite regression, but that regression is known and understood, and
will be addressed in the following.  (Please state such things in your
patch submissions.)  Also, I'm fine with getting work-in-progress stuff
committed on the branch, with the same expectations of mentioning this in
the submission, and completing the implementation later on.  Let's first
try to play this by email, but if it grows out of bound, perhaps a wiki
page will help to track known-broken/incomplete stuff?

As before, patches should be posted (with a [gomp4] tag) before
committing them, and at least be given some review and acknowledgement.
That is, consensus by the people interested in the topics worked on on
this branch.  Also, let's not be shy to ask GCC's area maintainers
(top-level MAINTAINERS file) for help (CC them in your submissions), for
example for front end changes.  It should be in their own interest to do
such review early ;-), as eventually all these changes aggregated on the
branch are to be merged into trunk.  Also, as far as possible, let's try
to get individual changes into trunk early, instead of aggregating lots
of stuff on gomp-4_0-branch, so that the diff between the two branches
doesn't grow too big (which makes branch maintenence difficult, such as
when doing merges from trunk).  (I'm aware this is less relevant/possible
until GCC 4.9 has branched.)

Jakub suggested (and I agree) the first thing to be done on
gomp-4_0-branch is a merge from trunk, which he hasn't done for a long
time.  I have prepared this yesterday morning, and have it ready for
commit, but...

..., now Samsung have posted,
patches for OpenACC support for Fortran, which likely will be conflicting
with the trunk merge as well as it does partially conflict with my
pending patch series for initial support for OpenACC data clauses,
Nevertheless, many thanks, Samsung people, for forward-porting this first
set of changes from your openacc-1_0-branch to gomp-4_0-branch!

We shall now work on integrating all this, and start reviewing the
patches that have been posted.  :-)


Attachment: pgpGCwuXkuzlH.pgp
Description: PGP signature

Reply via email to