From: Mark Mitchell <mark@codesourcery.com>
To: gcc@gcc.gnu.org
Subject: GCC 3.0.1
Date: Thu, 21 Jun 2001 14:13:00 -0000 [thread overview]
Message-ID: <59980000.993156803@localhost.localdomain> (raw)
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.
next reply other threads:[~2001-06-21 14:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-21 14:13 Mark Mitchell [this message]
2001-06-22 2:01 ` Joseph S. Myers
2001-06-22 11:24 ` Mark Mitchell
2001-08-16 11:05 Mark Mitchell
2001-10-14 7:51 gcc 3.0.1 Carlos F Sopuerta
2001-10-15 9:15 ` Janis Johnson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59980000.993156803@localhost.localdomain \
--to=mark@codesourcery.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).