*NB:* there will not be a GCC 3.5. The next release of GCC will be GCC 4.0.

*NB:* that dates on this page refer to the year 2004.

*See also Last-Minute_Requests_for_4.0.0 and GCC_4.1_Projects

The GCC Release Manager, Mark Mitchell, asked contributors to inform him of the projects they still had planned for GCC 4.0. Based on this information and discussions on the mailing list, he selected projects that would be allowed in for GCC 4.0, and project that have to be postponed until post-4.0.

Regressions to be fixed: all [[Regressions]]

Tree-SSA

The tree-ssa infrastructure (Diego Novillo et. al.)

Cleanups, etc.

There were a few submissions that are cleanups, or infrastructure improvements, on which nothing else depends, and which -- according to the submitters themselves -- do not bring substantial user-visible improvements. Those projects had to be submitted before the previously announced Stage 3 cutoff date: September 5th.

The only proposed project that has actually managed to make this deadline is:

Three other changes did not make the deadline so they have now been postponed.

Target/language-specific changes

As a general rule, decisions about target-specific and language-specific changes have been delegated by the RM to the discretion of the appropriate maintainers, at least until the release branch is created - and perhaps longer. So, for example, the Java ABI rework can go in during Stage 3, if the Java maintainers think that's OK, and the MIPS paired-float work can go in if the MIPS maintainers think it's OK. Maintainers are expected to exercise good judgement here, and err on the side of caution.

This delegation rule applies to the following language-specific changes:

In addition, the GCC Steering Committee has promised Apple (Zem Laski) that we will get Objective-C++ into GCC 4.0. Therefore, GCC 4.0 will not be released without Objective-C++, unless something seems to have gone horribly awry. *(Update)* Things went horribly awry, so Objective-C++ has not made it into GCC 4.0.

This delegation rule also applies to the following target-specific changes:

This delegation rule does *not* apply to the following changes, because the RM considers them to have too high a risk/reward ratio, and they will therefore be postponed until GCC 4.1:

If these get done, look very solid, and everyone wants them, they may be reconsidered.

For common code (including optimizations) similar responsibilities are not delegated to component maintainers because the consequences of changes there are much more far-reaching. Decisions about changes to common code can be taken only by the Release Manager.

Compile-Time Improvements

There were three submissions relating primarily to compile-time improvements. Since this has been a persistent problem, we'll allow these changes for GCC 4.0 -- if they can get finished quickly enough.

**This project is a catch-all. We will decide these on a per-change basis. Compile-time performance is a major issue. As in previous Stage 3s, and even on release branches, these changes will be OK, with appropriate maintainer approval -- but more localized, smaller changes will of course be favored over bigger changes.
_Update: changes deemed too invasive for stage 3 changes will happen on a branch_

Optimization Changes

There are a ton of these: a lot of people are working hard on a lot of really interesting projects. What the RM has done with these proposals is select those that have the best risk/reward/timeliness tradeoffs.

The following changes have been postponed until GCC 4.1 or later. These changes either provide too little benefit, are too risky, or will take too much time to complete.

None: What_will_be_in_4.0 (last edited 2008-01-10 19:38:42 by localhost)