From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: gcc@gcc.gnu.org Subject: GCC 3.0.1 Date: Thu, 21 Jun 2001 14:13:00 -0000 Message-id: <59980000.993156803@localhost.localdomain> X-SW-Source: 2001-06/msg01382.html 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.