GCC 3.0.1

[Mark Mitchell <mark at codesourcery dot com>]

I am pleased to see that the world did not stop spinning after we released 
GCC 3.0.

However, there are clearly some important issues that we need to fix, and 
for that
we need a GCC 3.0.1 release.

The GCC 3.0.1 release will be a critical bug-fix only release.  Relevant 
information follows.

Thank you,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Schedule
--------

2001-08-01	Release GCC 3.0.1

2001-07-21	Freeze, produce release candidate.

                All non-documentation changes after this point will be my 
express
                approval only.  I intend to make many fewer such approvals 
than
                I did during the final week before GCC 3.0.

2001-06-21	Begin development.

Procedures
----------

The check-in rules are similar to those preceding the 3.0 release.  In 
particular, every
check-in should fix a regression from GCC 2.95.x.  The usual people can 
approve patches
in the usual way.  Patches that cause regressions or bootstrap failures are 
liable to
be immediately removed.  Proceed with caution: it is vital that we not 
regress
relative to GCC 3.0 with the GCC 3.0.1 release.

There are no specific release criteria for this release.  However, the most 
critical issue is that we support more of the platforms that we did in GCC 
2.95.  For example, I know that the RTEMS platforms do not work well with 
GCC 3.0.  From conversations with Joel, many
of the problems are configury; let's fix those.  I know that there are 
bootstrap failures
and aborts on some embedded systems; let's fix those.  Our goal is to 
eventualy obsolete
GCC 2.95; in order to do that is that GCC 3.0.1 work well on lots of 
systems.

In addition, we should try to fix as many other problems as possible, 
especially cases
where we generate incorrect code.

Use of GNATS
------------

Let's again mark regressions from GCC 2.95.x as `high' priority bugs.  We 
don't need to
analyze every bug, but if you find a new regression, or you look at a PR 
and realize
it is a regression from GCC 2.95.x (or from GCC 3.0, heaven forbid!) mark 
it is as `high'.
We will *not* necessarily fix all such bugs -- but we can try.  Marking 
them `high' will
make it easy for us to find them.

Tantalizing Hint
----------------

Stay tuned for information about GCC 3.1.  The SC is continuing to debate 
how to approach
this release.  While there is no guarantee, I would expect resolution 
within the next
week or two.