This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 4.2.0 Status Report (2007-02-19)
- From: "Steven Bosscher" <stevenb dot gcc at gmail dot com>
- To: "Vladimir Makarov" <vmakarov at redhat dot com>
- Cc: "Mark Mitchell" <mark at codesourcery dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Tue, 20 Feb 2007 17:58:00 +0100
- Subject: Re: GCC 4.2.0 Status Report (2007-02-19)
- References: <45DA39B2.9010100@codesourcery.com> <45DB2317.6080208@redhat.com>
On 2/20/07, Vladimir Makarov <vmakarov@redhat.com> wrote:
>[Option 1] Instead of 4.2, we should backport some functionality from
>4.2 to the 4.1 branch, and call that 4.2.
>
>[Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
>that 4.2.
>
>[Option 3] Like (2), but create (the new) 4.2 branch before merging the
>dataflow code.
>
>
>
>
...
>Considering the options above:
>
>* I think [Option 3] is unfair to Kenny, Songbae, and others who have
>worked on dataflow code. The SC set criteria for that merge and a
>timeline to do the merge, and I believe that the dataflow code has met,
>or has nearly met, those criteria.
>
>
In term of ports, yes I am agree. As the preformance even with last
Paolo's patches (some changes could be applied to the mainline too, so
it is not only about df), the branch compiler is still 8.7% slower for
SPECint2000 compilation on 2.66Ghz Core2 with --enable-check=release.
I mostly agree with Vlad. IMHO the dataflow branch is in a state where
merging it early in a stage1 of a release cycle makes sense, but for
gcc 4.3 it is getting a bit late.
A lot depends on the current state of the trunk, of course. Do we also
have some quality indicators (bug numbers, compile time performance,
SPEC numbers, etc.) to compare it with the current gcc 4.2 and gcc 4.1
branches?
I don't think it would be very useful to stabilize the trunk if that
can't be done in a matter of, say, two months. If it takes longer than
that, releasing gcc 4.2 as-is would be my choice. Yes, there is a SPEC
performance gap, but SPEC is not the one-benchmark-to-rule-them-all,
and there are things in the current gcc 4.2 release branch (such as
OpenMP, and a hugely improved GFortran) that I would like to see
released.
Not releasing GCC 4.2 is IMHO not a really good option. If we do that,
GCC 4.3 will contain so much new code that the number of not yet
uncovered bugs that our users may run into, may be larger than we can
handle.
Gr.
Steven