This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GCC 4.0.1 Status Report (2005-05-26)

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]