3.4 to 3.5 libstdc++ changes

[Benjamin Kosnik]

>Thanks Benjamin for your summary.

Of course, you are welcome. We've put off dealing with this for too
long: it was good for you to bring this up.

>What can we realistically do at this point?

[snip]

I think your two suggestions are pretty much our two options. Either 3.4
and 3.5 match libstdc++ ABI's or they don't.

1) 3.4 and 3.5 ABI's match.

Then, I'd suggest the following. Merge mainline, modulo any
bootstrap-impacting change (I think one of your patches breaks an
obscure mips configuration and has been reverted on the branch.) In
addition, audit all the locale facets and try to future-proof them: all
should have the basic caching infrastructure in place, even if the
functions/data members are not used. The goal should be to slide
remaining work into the stable branch without changing the ABI.

Probably io should be audited as well. 

This assumes 3.4 tracks 3.5 after the merge. Then, two things. When
3.4.0 is released, a branch is created on mainline is created, maybe
something like libstdcxx_7_branch. All ABI-impacting libstdc++ work
would go on this branch so as to not be lost. Also, the ABI testing
would be beefed up to add in something equivalent to the LSB testing,
were instead of just looking at the export lists of the libstdc++ shared
library, all the API bits are examined.

Additions like a policy-based string class, or additional allocators,
can be added in ext.


2) 3.4 and 3.5 ABI's don't match.

If this is done, we could take the time to implement all the locale
caching, and have tested solutions for LFS, UTF8 filebufs, and try to
come up with a policy-based string class (see TODO). We'd have 3
libstdc++ ABI's (so 5 == 3.[23].x, so 6 == 3.4, so 7 == 3.5). 

This would still require fix-up to 3.4 to deal with the inconsistent
state of the allocator work. It would seem sensible to bring in the
string work as well.

Anyway.

I'm not really quite sure what to do. Suggestions from the GCC steering
committee members would be appreciated.

Part of me thinks we should really try for #1: it's what worked pretty
well for the 3.2/3.3.x series compilers, I think. It also allows the
maximum change in the 3.4 ABI, which I think is really wise. It's also
the most work. However, other people probably have other experiences
with the evolution of libstdc++ on the 3.2.x and 3.3.x branch: if so,
I'd like to hear details at this point. 

Part of me just thinks, fuck it, and have a full stretch of Stage 1 for
once! Whee!!! Fun without responsibility.

I will note that my frustration continues with trying to figure out the
libstdc++ bits in the context of the larger GCC development plan. It
seems as if Stage 1 for libstdc++ is always cut short while we (the
libstdc++ maintainers) concentrate on the release branch. Then, when the
release is finished, or in a stable state, we are in the twilight of
mainline's Stage 2. It never seems to work out well. There's got to be a
better way.

Oh well.

-benjamin