This is the mail archive of the 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]

GCC 3.0 Status Report


There are 25 days until the release of GCC 3.0.


Everyone worked very hard last week.  The new ABI-compliant exceptions
are working pretty smoothly at this point, and Richard Henderson is
helping people bang out the last few bugs and build failures.  Many
bugs were fixed.  There are presently about 30 high-priority bugs
reported, which is slightly down from last week.  The reason the
number isn't lower is that a few new regressions have been found
during the week.  Some of these bugs are Java bugs; it would be good
if the Java folks would try to close out some of these.

Bernd Schmidt helped me out by providing me the release script that he
has been using.  I am cleaning it up and tweaking it to make it
support the GCC 3.0 (and future) releases.  Bernd also fixed a
critical bug on the ARM.  Thank you Bernd!

At this point, my focus will be shifting from bug-fixing to packaging,
documentation, announcements, thank-yous and other similar issues.
That means that to make significant inroads against the open bugs,
other folks will have to step up and help.  There is one particularly
scary ARM bug where apparently GCC 3.0, once installed, cannot be used
to bootstrap itself.  I would definitely like to understand this
problem better.

Requests for Help

Please fix high-priority bugs.

Please continue to report regressions, and to review bugs in GNATS.

Soon, I will make prerelease test tarballs available.  These should be
packaged in the same way as the actual release will be.  Please
download them and try them out.  The most likely failure modes will be
things like that you can't build with the "core" and "c++" modules,
but without the "fortran" module, for example, or that you need
`autofoo' installed.  The prerelease tarballs will be built by cron on
a nightly basis, and posted for testing.  I will post a separate
announcement later.

Please work on documentation for the release.  Are there caveats, news
items, etc. that people should no about?  Are there undocumented
command-line options for your target?  Are there people who should be
thanked for their contributions?  Please collect such information and
send it to our documentation mainatiner: Gerald Pfeifer
<>.  (Gerald, if you would like to handle the
collection of this information in a different way, please feel free to
make an alternate announcement.)  And Gerald, please add yourself to
the thank-you list for doing a fabulous job as the documentation


Last week, I announced a June 15th release.  Once I get the release
script working, I will create a cronjob that will spin the release on
that date.  It will then require manual intervention to stop the
release from from happenning.  

(This is like sending a `launch commit' message to a nuclear missile;
it will proceed automatically to its target, even if all power fails
and the base is overrun by invaders, unless the override code is
entered.  Make of that analogy what you will.)

Below is the schedule for between now and the release.  This schedule
is designed to make sure that we are in a position to make the release
on the target date, rather than to make sure that the release is 100%
perfect at that point.  This is the tradeoff that we need to make at
this point; we've worked very hard to improve the quality of the
branch, we will now be working hard to make sure that the world gets
to see what we have done.

  Week of May 21

  - Prepare release script.

  - Prepare automated prerelease tarballs.

  - Continue to fix critical bugs.

  Week of May 28

  - I will be on vacation, starting May 26th. I will be in a part of
    the world that basically does not have internet access, so I will
    be totally offline.  I apologize for the poor timing, but the trip
    has been planned for months.

  - Immediate reversion policy.

    From this point forward, any patch which causes any new testsuite
    or bootstrap failures on any of our primary or secondary targets
    may be summarily reverted, without discussion.  It is more
    important that the majority of targets continue to function, and
    that people continue to have the opportunity to test them, than
    that any particular bug gets fixed.  If your patch is reverted,
    you can resubmit it after you figure out how to fix the problem,
    but you must have the revised patch reviewed again.  Tickling a
    latent bug, etc., is no excuse.  Think like a user: if it
    used to work, and now it doesn't, you broke it.

    Jeffrey Oldham will monitor the various automated builds that are
    posted nightly on CodeSourcery's server.  If he observes
    regressions in these builds from the previous day's results, he
    will identify the offending patch and remove it, posting a message
    indicating that he has done so.

    Any maintainer may take similar action, if so motivated, so as to 
    avoid waiting for Jeffrey.

  - Test prerelease tarballs.

  - Continue to fix critical bugs.
  - Application testing.

  Week of June 4
  - GNATS freeze.  

    No new bugs can be made high-priority after this date without
    my express approval, even if they are GCC 2.95 regressions.
    Please make every effort to review open bugs for your platform,
    and to perform application testing before this point.  Until
    this point, any maintainer can mark a bug high priority if it
    is a GCC 2.95 regression.

  - Continue to fix critical bugs.

  - Application testing.

  Week of June 11
  - Code freeze.

    No checkins will be allowed this week without my express
    approval.  Practically speaking, that means that we will be
    heavily bottlenecked at this point.  Please take advantage of
    the intervening time to work with all of the people who can
    approve patches to get your changes done.

  - Final documentation changes.

  - Final application testing.
  - Prepare release announcement.

  June 15th

   - Release GCC 3.0.
Volunteer of the Week

This week's volunteer is one of the truly versatile GCC developers.
He is also one of the most active reviewers of other people's patches.
Equally at home inn the IA64 back-end, the x86 back-end, and any part
of the optimizers, he took on the task of implementing a superior,
industry-standard exception-handling model.  This new
exception-handling model improves the size and performance of C++ and
Java code substantially, and will eventually allow GDB to set
breakpoints on a `throw' and see where the eventual `catch' will be.

The GCC 3.0 Volunteer of the Week is ...

   ... Richard Henderson.


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