Re: [tuples] Branch status and merge scenarios

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Apr 17, 2008 at 05:58:26PM -0700, Diego Novillo wrote:
> So, I see a couple different scenarios that we may want to consider:
> 
> 1- Push back and tell us to come back at the next stage 1.  This is
>    certainly the easiest for everyone else, and will create a few
>    challenges for us on the LTO branch.
> 
> 2- Once bootstrap is working for the major languages and targets, merge
>    and finish fixing remaining passes during stage 2.  Pass conversion
>    is highly mechanical, so I don't consider it risky for stage 2
>    stabilization.  We will be at this point in the 5-7 weeks I mentioned
>    earlier.

3- Delay the end of stage 1 till mid June or so.  I don't see the need to
rush out with 4.4 release, when it would have only limited advantages over
4.3 to offer.  Having IRA, Tuples, OpenMP3 (what other branches might be
mergeable by the GCC Summit time?) all in 4.4 is IMHO worth goal.  We could
then shorten stage2, or delay the expected 4.4. release date (the length of
stage4 is always unclear anyway).


The current OpenMP3 status is that most of the support is there, with the
major missing part is real unstubbed tasking support in libgomp (already
started, but could take 2-3 weeks), and more importantly the OpenMP 3.0
standard not released yet (I'm still hoping they can release it in the
spring as originally written somewhere, but no guarantees).

To resolve the Tuples vs. OpenMP3 conflicts before the standard is released,
there is an option to merge the gomp-3_0-branch to the trunk early (say in a
month) and just disallow new OpenMP 3.0 constructs in the frontends and
reenable them only when the standard is released, or create a separate
branch for tuples + OpenMP3 where I could work together with Aldy on
tuplifying the OpenMP3 additions.  Or OpenMP3 stuff can be made optional,
turned on with a separate option similarly to how G++ supports -std=c++0x,
and mark the -fopenmp3 support experimental.

	Jakub