This is the mail archive of the gcc@gcc.gnu.org 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]

time for bug triage?


We currently have 18 high-priority bugs against the 3.2 branch.  The
criterion we have for "high-priority" is "regression", that is, if any
previous gcc release doesn't show the bug, it's high priority.  This
implicitly states that the plan for 3.2.1 is to cure every problem ever
introduced into any 3.x-series compiler.  This is a worthy goal, but it
doesn't look achievable.  I'd be amazed if all 18 of these get fixed
this year.  I think that it is time for triage: subdivide into those
that really matter, and those that will just have to be put off.

Candidates I would include for reduced priority include the following:

- ICE's on illegal C++ code: 8036, 8149

- cross-compile build failure when srcdir == builddir: 7090

- things that have been broken a long time that may require more
  significant compiler changes, e.g. 7363 (bogus __alignof__ implementation),
  6162 (broken in all 3.x releases, requires inline assembly),
  8372 (ice on explicit call of destructor), 7385 (g++ problems with
  enum and __attribute__), 6718 (boost performance problem)

Of course, if someone already has a fix for any of the above, by all means
throw it in.  But we can still ship a compiler that is vastly better than
any 3.x compiler, with all the above bugs still present.

The bugs that look the worst to me are:

8334 (regression from 3.2): this looks like the kind of code that users
are likely to write.

8362 (bootstrap failure for AIX -mcpu=power)

I don't think we can ship anything with those two bugs.


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