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

development plans, priority items for 3.1



The roadmap for the gcc-3.1 release is specified here:

http://gcc.gnu.org/develop.html

Salient dates are:
2002-02-15  GCC 3.1 Stage 3 ends, branch created
2002-04-15  GCC 3.1.0 Release.

This roadmap specifies a nice orderly progression for the compilers,
but the target libraries are unspecified. Here's a suggestion for the
library: comments are welcome!

Goals:

1) Get ABI-breaking changes in ASAP
I'm sure we can throw around more acronyms here, if necessary.  I'm
proposing a date of Feb 05, 2002 for getting in larger,
binary-change-type patches. I think this is reasonable. Thoughts? It's
important to me to position gcc-3.1 as a long-lived ABI. (Since Red
Hat and presumably SuSe, Apple, others, will be using it for OS
releases.)
 
2) Close outstanding GNATS bugs
Good progress on this in the last month!

3) Complete more doxygen man pages, get more coverage on doxygen markup.
Phil made a release of the current-work. I suggest people check it out:
ftp://gcc.gnu.org/pub/libstdc++/doxygen/

I fully support the markup of the headers for this work. I'm playing
around with the indexes, and trying to figure out alternative
organization for names and symbols: maybe by chapter? Is that too
lame? Not stylish enough? It might be nice, if possible, to break
apart required names and symbols from implementation bits (ie __x or _X
names). 

4) Get more coverage in testsuite. 
Particularly weak is 23_containers.  Although it's not the most
glamorous thing, this is quite helpful. Coverage has increased by
about 100 tests between gcc-3.0 and gcc-3.1, which is really quite
nice.

5) Benchmark and tune.
Getting some kind of infrastructure in place to do this will be my
high priority around Feb, 2002. I hope others beat me to it. It would
be great to have the following metrics:
1) execution speed
2) binary size, static and shared
3) compilation time
4) memory usage
It's quite a wish list, but it would be useful. Loren, Paolo, and
Nathan have already done some good work in this area.

-benjamin


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