This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GCC 4.2.0 Status Report (2007-04-24)


[I apologize to those of you receiving duplicate copies of this mail.  I
thought so hard about copying people that I forgot to address to the list.]

Table of contents:

1. PRs
2. Schedule
3. Rationale

If you're in the CC: list, there are possible action items for you
below.  (Recent feedback was to provide more frequent status reports and
to nag more -- I'll do my best!)

PRs
===

At this point, we're very, very close to meeting the (admittedly
limited) goal for 4.2.0 of having no P1 regressions from 4.1.x.

The remaining PRs are:

1. PR 26792: libstdc++ on Darwin uses functions not present in the
system libgcc

This PR has apparently been fixed on the mainline.  If a Darwin
maintainer (Dale, Mike, Geoff) would like to backport this to 4.2, that
would be great.

2. PR 30222: crash on gcc.target/i386/vectorize1.c

This PR is apparently due to only part of a mainline patch being applied
to 4.2.  It was so diagnosed in December 2006, but nobody has identified
the missing part of the mainline patch.  Andrew, as you've diagnosed the
problem, would you please identify the solution?

3. PR 30567: Wrong code with -O3 due to aliasing problems

Richard G. has analyzed this and proposed a patch.  Richard, is this
ready to go?  If not, do you need help?

4. PR 31360: Missed optimization

I don't generally mark missed optimization bugs as P1, but not hoisting
loads of zero out of a 4-instruction loop is bad.  Zdenek has fixed this
on mainline.  Andrew says that patch has a bug.  So, what's the story here?

Schedule
========

I'm not going to consider any of these issues blockers after Sunday,
April 29.  At that point, I plan to freeze the branch and build a
release candidate.  Then, about a week later, I plan to release 4.2.0.
There has been more than enough time for people to test and fix bugs.

Rationale
=========

There are far too many constraints on releases to make everyone happy.
All of the following objectives and suggestions have been made by
intelligent, knowledgeable people:

1. Release early and often.
2. Take longer between releases so there's more time for major development.
3. Align releases with distributor schedules.
4. Take a feature-driven view: release when a pre-defined set of new
features are available.
5. Take a time-driven view: release on a particular date, no matter what.
6. Take a quality-driven view: release when there are no severe bugs.

I've gotten a little paralyzed with this release.  I've wanted to take
some combination of (4), (5), and (6), and I've made a hash of it.

I'm going to cut my losses and 4.2.0 out the door.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]