There are 163 regressions open against 4.0.1. Of these, 42 are critical, in the sense that they are wrong-code, ICE-on-valid, or rejects-valid. That's rather worse than we've done with previous releases; in part because we're carrying along bugs that we never get around to fixing from release to release, and in part because we've managed to introduce rather many new bugs in GCC 4.0.
The category about we should be most concerned is the wrong-code regressions, of which there are (unluckily) 13. (Of course, it is a now-fixed, but oft-encountered, wrong-code regression that is prompting us to want to move up the schedule for 4.0.1.) The following wrong-code regressions seem particularly troubling to me: 21562 Quiet bad codegen (unrolling + tail call interaction) 21171 IV OPTS removes does not create a new VOPs for constant values 21254 Incorrect code with -funroll-loops for multiple targets with same code 21528 Boost shared_ptr_test.cpp fails with -O3 21536 C99 array of variable length use causes segmentation fault 21614 wrong code when calling member function of undefined class I'd like to get these analyzed, and either fix them, or have a good argument that they cannot be practically fixed, before 4.0.1. A couple have already been fixed on the mainline; perhaps it is a simple matter to backport the offending patches. Let's give ourselves a week to fix these; i.e., until the end of June 3rd. Then, I'll take another look, and if it seems like we're not going to make good progress on any still remaining in short order, I'll do a prerelease, with a plan of a release on or about June 10th. During the next week, I'd encourage people to look through the 4.0.1 regressions and fix any others that seem important and/or tractable. I also want to make clear that I don't see it as our mission, or my duty as RM, to make releases every time we find a bug, even if those bugs seem rather critical. Certainly, toolchain distributors may need to do that, but that is not the purpose of the FSF releases. We do not have the resources, and doing releases interferes with development. Rushing to get releases out is a good way to introduce critical bug after critical bug, without ever achieving stability. We also make snapshots and CVS available for interested users who, for whatever reason, need a toolchain without the critical bug before the next official release. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED]
