gcc-2.95 and SGI STL 3.2

gcc-2.95 and SGI STL 3.2

[Ryszard Kabatek]

The source of gcc-2.95 is now frozen (June 15, 1999. Critical Bug Freeze Date),
but it does not contain the SGI STL 3.2.

Is it a final decision?

Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> The source of gcc-2.95 is now frozen (June 15, 1999. Critical Bug
> Freeze Date), but it does not contain the SGI STL 3.2.
>
> Is it a final decision?

I would think so, yes.

Martin

Re: gcc-2.95 and SGI STL 3.2

[Ryszard Kabatek]

On Thu, 17 Jun 1999, Martin v. Loewis wrote:

> > The source of gcc-2.95 is now frozen (June 15, 1999. Critical Bug
> > Freeze Date), but it does not contain the SGI STL 3.2.
> >
> > Is it a final decision?
> 
> I would think so, yes.

Are there any technical problems with the integration of the 3.2 version? 


Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129

Re: gcc-2.95 and SGI STL 3.2

[Jason Merrill]

>>>>> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:

 > Are there any technical problems with the integration of the 3.2 version? 

No, just that nobody has taken the initiative.

Jason

Re: gcc-2.95 and SGI STL 3.2

[Gabriel Dos_Reis]

Jason Merrill <jason@cygnus.com> writes:

| >>>>> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
| 
|  > Are there any technical problems with the integration of the 3.2 version? 
| 
| No, just that nobody has taken the initiative.

I'll take that as an approval. Is it too late to make the merge?

-- Gaby

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < xajhfo5ny0y.fsf@korrigan.inria.fr >you write:
  > | No, just that nobody has taken the initiative.
  > 
  > I'll take that as an approval. Is it too late to make the merge?
I think it's too late now.  Even if you merged it right now, we're only 3-4
weeks away from the release.

Perhaps this should be something for gcc-2.95.1?

jeff

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> Perhaps this should be something for gcc-2.95.1?

Before making that change, it should be well-established that
integrating STL 3.2 wouldn't break binary compatibility with gcc 2.95.
Given past experience, it likely will (no, I haven't analyzed this at
all).

What important new features will STL 3.2 give us, anyway?

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Joe Buck]

> > Perhaps this should be something for gcc-2.95.1?
> 
> Before making that change, it should be well-established that
> integrating STL 3.2 wouldn't break binary compatibility with gcc 2.95.
> Given past experience, it likely will (no, I haven't analyzed this at
> all).

That's a factor that makes it really too bad that we didn't manage to
make the change for gcc-2.95: it then means we can't make the change
for later minor releases either.

> What important new features will STL 3.2 give us, anyway?

Performance improvements and bug fixes, principally.  See
http://www.sgi.com/Technology/STL/whats_new.html

Unfortunately, upgrading egcs/gcc to a new STL is not trivial, as SGI
is providing some classes that we are also providing, so it takes a bit
of care to figure out exactly what to leave out and then to make sure
that this doesn't break anything.

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < 199906192259.AAA00649@mira.isdn.cs.tu-berlin.de >you write:
  > > Perhaps this should be something for gcc-2.95.1?
  > 
  > Before making that change, it should be well-established that
  > integrating STL 3.2 wouldn't break binary compatibility with gcc 2.95.
  > Given past experience, it likely will (no, I haven't analyzed this at
  > all).
That would be a serious concern.  I'd have to rely on you and the rest of
the C++ folks to evaluate that issue.

jeff

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> That would be a serious concern.  I'd have to rely on you and the
> rest of the C++ folks to evaluate that issue.

Ok, here is a quick analysis.

First, what if we integrate now:

STL 3.2 defines a number of new configuration options, which would
need to be carefully selected when integrating it into gcc - whoever
is going to do this probably knows that.

Now, what if we integrate STL into gcc 2.95.1:

On SGI, the new library is not binary compatible with the old one, as
they now use _S_node_allocator instead of _S_lock, following all other
thread systems.

In stl_bvector.h, there is a new function _M_fill_assign (which is
wrapped by assign). This would normally not introduce an
incompatibility, except when somebody uses -fno-implicit-templates,
and the template instantiations are in a library produced with an
older compiler (i.e. gcc 2.95). There is a number of problems of that
kind throughout STL: a large number of ordering operators (==, <, ...)
was added.

constant_binary_fun now inherits from _Constant_binary_fun. I don't
think this could cause a problem.

Partial specializations of insert_iterator etc are now provided. This
will break the ABI for applications which pass those iterators around.
In fact, iterators changed so much I can't overlook the changes.

The layout of the internal rope classes changed.

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Gabriel Dos_Reis]

Jeffrey A Law <law@cygnus.com> writes:

|   In message < xajhfo5ny0y.fsf@korrigan.inria.fr >you write:
|   > | No, just that nobody has taken the initiative.
|   > 
|   > I'll take that as an approval. Is it too late to make the merge?
| I think it's too late now.  Even if you merged it right now, we're only 3-4
| weeks away from the release.
| 
| Perhaps this should be something for gcc-2.95.1?

That is Ok for me.

-- Gaby

Re: gcc-2.95 and SGI STL 3.2

[mark]

I think would be inappropriate to integrate STL 3.2 now.  We are
supposed to be in critical bug-fix mode, putting in changes which:

  o Fix serious problems.
  o Clearly to do not break things.

It's not clear that STL 3.2 meets either criterion, even though it
does fix some bugs.

I don't think this is appropriate for a dot-release either.  There we
should be doing more serious bug-fixing, and we shouln't take chances
with binary compatibility, except to fix bugs.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

STL 3.2 has one very important advantage (at least in things I'm
involved in) - it is thread-safe.


Dima

On Sun, 20 Jun 1999 09:26:13 -0700, you wrote:

>
>I think would be inappropriate to integrate STL 3.2 now.  We are
>supposed to be in critical bug-fix mode, putting in changes which:
>
>  o Fix serious problems.
>  o Clearly to do not break things.
>
>It's not clear that STL 3.2 meets either criterion, even though it
>does fix some bugs.
>
>I don't think this is appropriate for a dot-release either.  There we
>should be doing more serious bug-fixing, and we shouln't take chances
>with binary compatibility, except to fix bugs.
>
>--
>Mark Mitchell                   mark@codesourcery.com
>CodeSourcery, LLC               http://www.codesourcery.com
>

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> STL 3.2 has one very important advantage (at least in things I'm
> involved in) - it is thread-safe.

Can you elaborate? The STL memory allocator was always
thread-safe. What template is thread-safe now that wasn't in the past?

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

On Sun, 20 Jun 1999 19:11:07 +0200, you wrote:

>> STL 3.2 has one very important advantage (at least in things I'm
>> involved in) - it is thread-safe.
>
>Can you elaborate? The STL memory allocator was always
>thread-safe. What template is thread-safe now that wasn't in the past?

<string>, see the thread starting with
http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html

Another STL-related (but not STL's) problem in the status quo (in 1.1.2,
I haven't had enough time to check the latest snapshots, sorry) -

T __default_alloc_template<0, 0>::.....
                           ^
in libstdc++ (that is non-thread-safe instantiations for lots of stuff),
but it's kind of explicitly recognized in the bugs/todo list.


>Martin

Dima

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> >> STL 3.2 has one very important advantage (at least in things I'm
> >> involved in) - it is thread-safe.
[which class?]
> <string>, see the thread starting with
> http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html

In that case, updating STL won't give you anything: gcc does not use
<string> from STL. I don't know what the rationale is, but I
personally prefer the multithreading bug be fixed, instead of using a
completely different implementation.

As for libstdc++ v3: It seems there is yet another string
implementation, (apparently) contributed by Nathan Myers.

> Another STL-related (but not STL's) problem in the status quo (in 1.1.2,
> I haven't had enough time to check the latest snapshots, sorry) -
> 
> T __default_alloc_template<0, 0>::.....
>                            ^
> in libstdc++ (that is non-thread-safe instantiations for lots of stuff),
> but it's kind of explicitly recognized in the bugs/todo list.

That is fixed in gcc 2.95, I believe.

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Benjamin Scherrey]

"Martin v. Loewis" wrote:
> 
> > >> STL 3.2 has one very important advantage (at least in things I'm
> > >> involved in) - it is thread-safe.
> [which class?]
> > <string>, see the thread starting with
> > http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html
> 
> In that case, updating STL won't give you anything: gcc does not use
> <string> from STL. I don't know what the rationale is, but I
> personally prefer the multithreading bug be fixed, instead of using a
> completely different implementation.
<rest snipped>

	Regarding the latest SGI STL, I had been working under the assumption
that it was planned to be included in the next major egcs release
(presumably gcc-2.95). Its my impression that it will break binary
compatibility which seems to be the consensus here as well. I think
its kindof a now or almost never decision isn't it? 2.95 is going to
be a major change and breaking old stuff might well be expected
although screams will certainly ensue regardless. Should we not then
expect that future releases will (almost) never (or certainly not for
a very long time) break binary compatibility? If so then that would
make integration of STL 3.2 something that might never be feasible in
which case we are now choosing to be "left behind" in the SGI tree. Is
that important to egcs developers/users? I really don't know but it
doesn't strike me as a good thing at first impression. The only other
major opportunity for integration I can think of is when the new
c++stdlib is finally integrated but I don't foresee that happening
anytime this year at its present rate of progress.

	I'd appreciate any corrections to my current impressions that others
more knowledgeable than me (that's pretty much all of you) might have
to offer.
	
	thanx & later,

		Ben Scherrey

Re: gcc-2.95 and SGI STL 3.2

[craig]

Just to add my two cents, FWIW:

  -  gcc 3.0 is an "event" that many people will expect to require
     recompiling anyway, so things like a new STL could happen there.

  -  gcc 2.95 might be "big enough" without the new STL for the gcc
     community, especially those users who have not already switched
     to EGCS, and thus will see it as the "next" version after 2.8.1.
     (I know basically nothing about the STL issues, and therefore have
     no opinion on them.)

  -  gcc 3.0 also is my personal target for the g77 0.6 rewrite, which
     will have some substantial effects on behaviors of g77 that people
     are used to, which is why I really hope to get it into 3.0, not
     3.1, 3.2, etc., and not wait for 4.0.

  -  Someday g77 really needs to break away from libf2c, and define
     its own library, libg77.  3.0 would be great for this, but I doubt
     it'll happen -- the 0.6 rewrite (which involves the front end,
     not the run-time library) is a big-enough task for me now.  That
     means libg77 would be a gcc 4.0 item, though possibly we could
     decide on it being a 3.X item, since we still speak of g77 being
     in "beta".

        tq vm, (burley)

Re: gcc-2.95 and SGI STL 3.2

[Jason Merrill]

I don't feel strongly about integrating 3.2 now; I think it's a mistake
that we didn't do it before.  I had been waiting for Ulrich to take the
initiative.  I would be opposed to doing it in a dot release, as it would
break binary compatibility.

Jason

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>:

>> >> STL 3.2 has one very important advantage (at least in things I'm
>> >> involved in) - it is thread-safe.
> [which class?]
>> <string>, see the thread starting with
>> http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html

> In that case, updating STL won't give you anything: gcc does not use
> <string> from STL. I don't know what the rationale is,

The native g++ <string> uses refcounting.  The SGI STL <string> always
does a deep copy.

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> craig@jcb-sc.com:

> Just to add my two cents, FWIW:
>   -  gcc 3.0 is an "event" that many people will expect to require
>      recompiling anyway, so things like a new STL could happen there.

gcc 3.0 will presumably use libstdc++-v3, which currently includes SGI 
STL 3.2:
        http://sourceware.cygnus.com/libstdc++/faq/index.html#5_3

Re: gcc-2.95 and SGI STL 3.2

[Tim Waugh]

On 21 Jun 1999, Steinar Bang wrote:

> The native g++ <string> uses refcounting.  The SGI STL <string> always
> does a deep copy.

I don't think refcounting actually helps much with strings -- you have to
do a deep copy whenever the data is accessed anyway (even read: think
'string s="str",t; char &c=s[0];').

Tim.
*/

Re: gcc-2.95 and SGI STL 3.2

[Ryszard Kabatek]

On 20 Jun 1999, Jason Merrill wrote:

> I don't feel strongly about integrating 3.2 now; I think it's a mistake
> that we didn't do it before.  I had been waiting for Ulrich to take the
> initiative.  I would be opposed to doing it in a dot release, as it would
> break binary compatibility.

Supposing, the STL 3.2 (or higher) will be integrated into the next 
gcc release (gcc-2.96). So it means, the 2.96 rel. will be binary incompatible
with the 2.95. 

In egcs it was possible, but now it is an official gcc release.
The distributions like RedHat, SuSE, and so far, will probably boycott the
2.96 release. A lot of people uses the compiler shipped with a distribution...


Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < whhfo281u5.fsf@viffer.oslo.metis.no >you write:
  > gcc 3.0 will presumably use libstdc++-v3, which currently includes SGI 
  > STL 3.2:
  >         http://sourceware.cygnus.com/libstdc++/faq/index.html#5_3
That is the plan and the finishing the new libstdc++ is probably the
biggest gating factor for the gcc-3.0 schedule.

If it turns out that the new libstdc++ is still a ways off, we can still
spin a gcc-2.96 release.

jeff

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> Tim Waugh <tim@cyberelk.demon.co.uk>:

> On 21 Jun 1999, Steinar Bang wrote:
>> The native g++ <string> uses refcounting.  The SGI STL <string> always
>> does a deep copy.

> I don't think refcounting actually helps much with strings -- you have to
> do a deep copy whenever the data is accessed anyway (even read: think
> 'string s="str",t; char &c=s[0];').

YMMV.  If you address the char[] data directly all the time, it won't
help much.  I don't do that except in special circumstances.

If you pass strings along as lot, hold them in temporary copies and
mostly use streams to input and output them, refcounting will help.

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < 19990621032446.2159.qmail@deer >you write:
  >   -  gcc 3.0 is an "event" that many people will expect to require
  >      recompiling anyway, so things like a new STL could happen there.
Yup.

  >   -  gcc 2.95 might be "big enough" without the new STL for the gcc
  >      community, especially those users who have not already switched
  >      to EGCS, and thus will see it as the "next" version after 2.8.1.
  >      (I know basically nothing about the STL issues, and therefore have
  >      no opinion on them.)
gcc-2.95 certainly a big jump for those who haven't already switched to the
egcs line of development.  Remember the C++ compiler in gcc-2.8 is old, like
a full 2 years old.  

gcc-2.95 is much less of a jump for those who have been tracking the egcs-1.0,
egcs-1.1 releases.  While I've been told gcc-2.95 will be binary incompatible
with egcs-1.1.2 due to C++ issues, I've actually yet to have any problems 
with linking egcs-1.1.2 C++ libraries with gcc-2.95 C++ code.

  >   -  Someday g77 really needs to break away from libf2c, and define
  >      its own library, libg77.  3.0 would be great for this, but I doubt
  >      it'll happen -- the 0.6 rewrite (which involves the front end,
  >      not the run-time library) is a big-enough task for me now.  That
  >      means libg77 would be a gcc 4.0 item, though possibly we could
  >      decide on it being a 3.X item, since we still speak of g77 being
  >      in "beta".
I think replacing libf2c with libg77 would be a reasonable item to add in a
3.x release if we do not get it into gcc-3.0.

jeff

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

On Mon, 21 Jun 1999 09:09:42 +0100 (GMT), you wrote:

>On 21 Jun 1999, Steinar Bang wrote:
>
>> The native g++ <string> uses refcounting.  The SGI STL <string> always
>> does a deep copy.
>
>I don't think refcounting actually helps much with strings -- you have to
>do a deep copy whenever the data is accessed anyway (even read: think
>'string s="str",t; char &c=s[0];').

Besides, in a multi-threaded environment, refcounting requires an extra
mutex, which has to be used for _every_ string operation and thus
introduces a very heavy performance penalty compared with a
straightforward implementation without shared data.

>Tim.

Cheers!

Dima

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> dvv@dvv.ru (Dima Volodin):

> On Mon, 21 Jun 1999 09:09:42 +0100 (GMT), you wrote:
>> On 21 Jun 1999, Steinar Bang wrote:
>> 
>>> The native g++ <string> uses refcounting.  The SGI STL <string> always
>>> does a deep copy.

>> I don't think refcounting actually helps much with strings -- you
>> have to do a deep copy whenever the data is accessed anyway (even
>> read: think 'string s="str",t; char &c=s[0];').

> Besides, in a multi-threaded environment, refcounting requires an
> extra mutex,...

There's an article by Herb Sutter in the june 1999 issue of the C/C++
Users Journal
        http://www.cuj.com/archive/1706/
(no online version of the article, unfortunately), that addresses
refcounting in a multithreaded world.  It uses something called
"atomic integer operations" to do thread-safe refcounting at a lower
cost than mutex operations.

But as I understand it, these operations may not be available on all
systems, and if they are, may have different interfaces.

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

On 22 Jun 1999 09:01:25 +0200, Steinar Bang <sb@metis.no> wrote:

>>>>>> dvv@dvv.ru (Dima Volodin):
>> Besides, in a multi-threaded environment, refcounting requires an
>> extra mutex,...
>
>There's an article by Herb Sutter in the june 1999 issue of the C/C++
>Users Journal
>        http://www.cuj.com/archive/1706/
>(no online version of the article, unfortunately), that addresses
>refcounting in a multithreaded world.  It uses something called
>"atomic integer operations" to do thread-safe refcounting at a lower
>cost than mutex operations.

This is exactly the problem with this approach:

>But as I understand it, these operations may not be available on all
>systems, and if they are, may have different interfaces.

Besides, doing atomic operations is not enough for guaranteeing data
consistency - it's a recurring topic on comp.programming.threads, you
might want to check Dave Butenhof's articles there or just get his book
and see the part about the memory model in POSIX threads.

After some thought given to the subject of <string>, I don't think
anymore that every operation needs mutex locking, but only those which
deal with the ref counter. My guess is these operations are the same as
those explicitly marked in the Standard to invalidate references,
pointers and iterators (21.3/5).

Anyway, having to deal with mutexes breaks the binary compatibility
whichever way you implement it - the inlined code in old libraries won't
know anything about the need to protect ref counters with
synchronization primitives - no matter what these pimitives are.


Dima

Re: gcc-2.95 and SGI STL 3.2

[Benjamin Kosnik]

> After some thought given to the subject of <string>, I don't think
> anymore that every operation needs mutex locking, but only those which
> deal with the ref counter. My guess is these operations are the same as
> those explicitly marked in the Standard to invalidate references,
> pointers and iterators (21.3/5).


This is exactly what I would think as well. These include the non-const at,
operator[], begin, end, rbegin, and rend. I'll need to take a look at the
article before I know for sure.

-Benjamin

Re: gcc-2.95 and SGI STL 3.2

[Richard Henderson]

On Tue, Jun 22, 1999 at 12:39:01PM +0000, Dima Volodin wrote:
> >But as I understand it, these operations may not be available on all
> >systems, and if they are, may have different interfaces.
> 
> Besides, doing atomic operations is not enough for guaranteeing data
> consistency - it's a recurring topic on comp.programming.threads, you
> might want to check Dave Butenhof's articles there or just get his book
> and see the part about the memory model in POSIX threads.

There aren't that many variations that need to be delt with,
and the win speedwise is large enough it's worth the effort.

Just consider everything to use a relaxed memory order and
define macros that ensure ordering of a particular type
(load-load, load-store, store-load, store-store, and sync).
For systems that ensure one of those naturally, the macro
becomes an effective nop.

As for the different interfaces to the atomic operations, all of
the interesting extant processors support either atomic add (i386,
ia64), compare and exchange (m68k, i486, sparcv9, ia64) or load
locked store conditional (mips, alpha, ppc).  Again, not that
many variants to choose from.


r~

Re: gcc-2.95 and SGI STL 3.2

[Joe Buck]

> On 21 Jun 1999, Steinar Bang wrote:
> 
> > The native g++ <string> uses refcounting.  The SGI STL <string> always
> > does a deep copy.
> 
> I don't think refcounting actually helps much with strings -- you have to
> do a deep copy whenever the data is accessed anyway (even read: think
> 'string s="str",t; char &c=s[0];').

You are not correct, you don't have to do a deep copy whenever the data
is accessed.  On a writable string, using begin(), end(), or [] on a
string with multiple references will require a deep copy.  However, those
same operations on a const string& will not require a copy, and
furthermore there are many other ways to access string data that don't
need a copy.  So in practice, programs that use strings a lot typically
have many references to the same string representation object (including
most of what I've written).  Switching to the SGI scheme would have
a substantial cost.

Re: gcc-2.95 and SGI STL 3.2

[Tim Waugh]

On Fri, 25 Jun 1999, Joe Buck wrote:

> You are not correct, you don't have to do a deep copy whenever the data
> is accessed.  On a writable string, using begin(), end(), or [] on a
> string with multiple references will require a deep copy.  However, those
> same operations on a const string& will not require a copy, and

Ah, good point.  I hadn't thought of the const case.  Sorry for spreading
misinformation.

Tim.
*/

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

On 22 Jun 1999 09:01:25 +0200, Steinar Bang <sb@metis.no> wrote:

>>>>>> dvv@dvv.ru (Dima Volodin):
>> Besides, in a multi-threaded environment, refcounting requires an
>> extra mutex,...
>
>There's an article by Herb Sutter in the june 1999 issue of the C/C++
>Users Journal
>        http://www.cuj.com/archive/1706/
>(no online version of the article, unfortunately), that addresses
>refcounting in a multithreaded world.  It uses something called
>"atomic integer operations" to do thread-safe refcounting at a lower
>cost than mutex operations.

This is exactly the problem with this approach:

>But as I understand it, these operations may not be available on all
>systems, and if they are, may have different interfaces.

Besides, doing atomic operations is not enough for guaranteeing data
consistency - it's a recurring topic on comp.programming.threads, you
might want to check Dave Butenhof's articles there or just get his book
and see the part about the memory model in POSIX threads.

After some thought given to the subject of <string>, I don't think
anymore that every operation needs mutex locking, but only those which
deal with the ref counter. My guess is these operations are the same as
those explicitly marked in the Standard to invalidate references,
pointers and iterators (21.3/5).

Anyway, having to deal with mutexes breaks the binary compatibility
whichever way you implement it - the inlined code in old libraries won't
know anything about the need to protect ref counters with
synchronization primitives - no matter what these pimitives are.


Dima

Re: gcc-2.95 and SGI STL 3.2

[Tim Waugh]

On Fri, 25 Jun 1999, Joe Buck wrote:

> You are not correct, you don't have to do a deep copy whenever the data
> is accessed.  On a writable string, using begin(), end(), or [] on a
> string with multiple references will require a deep copy.  However, those
> same operations on a const string& will not require a copy, and

Ah, good point.  I hadn't thought of the const case.  Sorry for spreading
misinformation.

Tim.
*/

Re: gcc-2.95 and SGI STL 3.2

[Gabriel Dos_Reis]

Jeffrey A Law <law@cygnus.com> writes:

|   In message < xajhfo5ny0y.fsf@korrigan.inria.fr >you write:
|   > | No, just that nobody has taken the initiative.
|   > 
|   > I'll take that as an approval. Is it too late to make the merge?
| I think it's too late now.  Even if you merged it right now, we're only 3-4
| weeks away from the release.
| 
| Perhaps this should be something for gcc-2.95.1?

That is Ok for me.

-- Gaby

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> >> STL 3.2 has one very important advantage (at least in things I'm
> >> involved in) - it is thread-safe.
[which class?]
> <string>, see the thread starting with
> http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html

In that case, updating STL won't give you anything: gcc does not use
<string> from STL. I don't know what the rationale is, but I
personally prefer the multithreading bug be fixed, instead of using a
completely different implementation.

As for libstdc++ v3: It seems there is yet another string
implementation, (apparently) contributed by Nathan Myers.

> Another STL-related (but not STL's) problem in the status quo (in 1.1.2,
> I haven't had enough time to check the latest snapshots, sorry) -
> 
> T __default_alloc_template<0, 0>::.....
>                            ^
> in libstdc++ (that is non-thread-safe instantiations for lots of stuff),
> but it's kind of explicitly recognized in the bugs/todo list.

That is fixed in gcc 2.95, I believe.

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Benjamin Kosnik]

> After some thought given to the subject of <string>, I don't think
> anymore that every operation needs mutex locking, but only those which
> deal with the ref counter. My guess is these operations are the same as
> those explicitly marked in the Standard to invalidate references,
> pointers and iterators (21.3/5).


This is exactly what I would think as well. These include the non-const at,
operator[], begin, end, rbegin, and rend. I'll need to take a look at the
article before I know for sure.

-Benjamin

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < 199906192259.AAA00649@mira.isdn.cs.tu-berlin.de >you write:
  > > Perhaps this should be something for gcc-2.95.1?
  > 
  > Before making that change, it should be well-established that
  > integrating STL 3.2 wouldn't break binary compatibility with gcc 2.95.
  > Given past experience, it likely will (no, I haven't analyzed this at
  > all).
That would be a serious concern.  I'd have to rely on you and the rest of
the C++ folks to evaluate that issue.

jeff

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> Tim Waugh <tim@cyberelk.demon.co.uk>:

> On 21 Jun 1999, Steinar Bang wrote:
>> The native g++ <string> uses refcounting.  The SGI STL <string> always
>> does a deep copy.

> I don't think refcounting actually helps much with strings -- you have to
> do a deep copy whenever the data is accessed anyway (even read: think
> 'string s="str",t; char &c=s[0];').

YMMV.  If you address the char[] data directly all the time, it won't
help much.  I don't do that except in special circumstances.

If you pass strings along as lot, hold them in temporary copies and
mostly use streams to input and output them, refcounting will help.

Re: gcc-2.95 and SGI STL 3.2

[Richard Henderson]

On Tue, Jun 22, 1999 at 12:39:01PM +0000, Dima Volodin wrote:
> >But as I understand it, these operations may not be available on all
> >systems, and if they are, may have different interfaces.
> 
> Besides, doing atomic operations is not enough for guaranteeing data
> consistency - it's a recurring topic on comp.programming.threads, you
> might want to check Dave Butenhof's articles there or just get his book
> and see the part about the memory model in POSIX threads.

There aren't that many variations that need to be delt with,
and the win speedwise is large enough it's worth the effort.

Just consider everything to use a relaxed memory order and
define macros that ensure ordering of a particular type
(load-load, load-store, store-load, store-store, and sync).
For systems that ensure one of those naturally, the macro
becomes an effective nop.

As for the different interfaces to the atomic operations, all of
the interesting extant processors support either atomic add (i386,
ia64), compare and exchange (m68k, i486, sparcv9, ia64) or load
locked store conditional (mips, alpha, ppc).  Again, not that
many variants to choose from.


r~

Re: gcc-2.95 and SGI STL 3.2

[Gabriel Dos_Reis]

Jason Merrill <jason@cygnus.com> writes:

| >>>>> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:
| 
|  > Are there any technical problems with the integration of the 3.2 version? 
| 
| No, just that nobody has taken the initiative.

I'll take that as an approval. Is it too late to make the merge?

-- Gaby

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> STL 3.2 has one very important advantage (at least in things I'm
> involved in) - it is thread-safe.

Can you elaborate? The STL memory allocator was always
thread-safe. What template is thread-safe now that wasn't in the past?

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

On Sun, 20 Jun 1999 19:11:07 +0200, you wrote:

>> STL 3.2 has one very important advantage (at least in things I'm
>> involved in) - it is thread-safe.
>
>Can you elaborate? The STL memory allocator was always
>thread-safe. What template is thread-safe now that wasn't in the past?

<string>, see the thread starting with
http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html

Another STL-related (but not STL's) problem in the status quo (in 1.1.2,
I haven't had enough time to check the latest snapshots, sorry) -

T __default_alloc_template<0, 0>::.....
                           ^
in libstdc++ (that is non-thread-safe instantiations for lots of stuff),
but it's kind of explicitly recognized in the bugs/todo list.


>Martin

Dima

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < xajhfo5ny0y.fsf@korrigan.inria.fr >you write:
  > | No, just that nobody has taken the initiative.
  > 
  > I'll take that as an approval. Is it too late to make the merge?
I think it's too late now.  Even if you merged it right now, we're only 3-4
weeks away from the release.

Perhaps this should be something for gcc-2.95.1?

jeff

Re: gcc-2.95 and SGI STL 3.2

[craig]

Just to add my two cents, FWIW:

  -  gcc 3.0 is an "event" that many people will expect to require
     recompiling anyway, so things like a new STL could happen there.

  -  gcc 2.95 might be "big enough" without the new STL for the gcc
     community, especially those users who have not already switched
     to EGCS, and thus will see it as the "next" version after 2.8.1.
     (I know basically nothing about the STL issues, and therefore have
     no opinion on them.)

  -  gcc 3.0 also is my personal target for the g77 0.6 rewrite, which
     will have some substantial effects on behaviors of g77 that people
     are used to, which is why I really hope to get it into 3.0, not
     3.1, 3.2, etc., and not wait for 4.0.

  -  Someday g77 really needs to break away from libf2c, and define
     its own library, libg77.  3.0 would be great for this, but I doubt
     it'll happen -- the 0.6 rewrite (which involves the front end,
     not the run-time library) is a big-enough task for me now.  That
     means libg77 would be a gcc 4.0 item, though possibly we could
     decide on it being a 3.X item, since we still speak of g77 being
     in "beta".

        tq vm, (burley)

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < whhfo281u5.fsf@viffer.oslo.metis.no >you write:
  > gcc 3.0 will presumably use libstdc++-v3, which currently includes SGI 
  > STL 3.2:
  >         http://sourceware.cygnus.com/libstdc++/faq/index.html#5_3
That is the plan and the finishing the new libstdc++ is probably the
biggest gating factor for the gcc-3.0 schedule.

If it turns out that the new libstdc++ is still a ways off, we can still
spin a gcc-2.96 release.

jeff

Re: gcc-2.95 and SGI STL 3.2

[Ryszard Kabatek]

On 20 Jun 1999, Jason Merrill wrote:

> I don't feel strongly about integrating 3.2 now; I think it's a mistake
> that we didn't do it before.  I had been waiting for Ulrich to take the
> initiative.  I would be opposed to doing it in a dot release, as it would
> break binary compatibility.

Supposing, the STL 3.2 (or higher) will be integrated into the next 
gcc release (gcc-2.96). So it means, the 2.96 rel. will be binary incompatible
with the 2.95. 

In egcs it was possible, but now it is an official gcc release.
The distributions like RedHat, SuSE, and so far, will probably boycott the
2.96 release. A lot of people uses the compiler shipped with a distribution...


Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> The source of gcc-2.95 is now frozen (June 15, 1999. Critical Bug
> Freeze Date), but it does not contain the SGI STL 3.2.
>
> Is it a final decision?

I would think so, yes.

Martin

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

STL 3.2 has one very important advantage (at least in things I'm
involved in) - it is thread-safe.


Dima

On Sun, 20 Jun 1999 09:26:13 -0700, you wrote:

>
>I think would be inappropriate to integrate STL 3.2 now.  We are
>supposed to be in critical bug-fix mode, putting in changes which:
>
>  o Fix serious problems.
>  o Clearly to do not break things.
>
>It's not clear that STL 3.2 meets either criterion, even though it
>does fix some bugs.
>
>I don't think this is appropriate for a dot-release either.  There we
>should be doing more serious bug-fixing, and we shouln't take chances
>with binary compatibility, except to fix bugs.
>
>--
>Mark Mitchell                   mark@codesourcery.com
>CodeSourcery, LLC               http://www.codesourcery.com
>

Re: gcc-2.95 and SGI STL 3.2

[Ryszard Kabatek]

On Thu, 17 Jun 1999, Martin v. Loewis wrote:

> > The source of gcc-2.95 is now frozen (June 15, 1999. Critical Bug
> > Freeze Date), but it does not contain the SGI STL 3.2.
> >
> > Is it a final decision?
> 
> I would think so, yes.

Are there any technical problems with the integration of the 3.2 version? 


Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129

Re: gcc-2.95 and SGI STL 3.2

[Jason Merrill]

I don't feel strongly about integrating 3.2 now; I think it's a mistake
that we didn't do it before.  I had been waiting for Ulrich to take the
initiative.  I would be opposed to doing it in a dot release, as it would
break binary compatibility.

Jason

Re: gcc-2.95 and SGI STL 3.2

[Dima Volodin]

On Mon, 21 Jun 1999 09:09:42 +0100 (GMT), you wrote:

>On 21 Jun 1999, Steinar Bang wrote:
>
>> The native g++ <string> uses refcounting.  The SGI STL <string> always
>> does a deep copy.
>
>I don't think refcounting actually helps much with strings -- you have to
>do a deep copy whenever the data is accessed anyway (even read: think
>'string s="str",t; char &c=s[0];').

Besides, in a multi-threaded environment, refcounting requires an extra
mutex, which has to be used for _every_ string operation and thus
introduces a very heavy performance penalty compared with a
straightforward implementation without shared data.

>Tim.

Cheers!

Dima

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> That would be a serious concern.  I'd have to rely on you and the
> rest of the C++ folks to evaluate that issue.

Ok, here is a quick analysis.

First, what if we integrate now:

STL 3.2 defines a number of new configuration options, which would
need to be carefully selected when integrating it into gcc - whoever
is going to do this probably knows that.

Now, what if we integrate STL into gcc 2.95.1:

On SGI, the new library is not binary compatible with the old one, as
they now use _S_node_allocator instead of _S_lock, following all other
thread systems.

In stl_bvector.h, there is a new function _M_fill_assign (which is
wrapped by assign). This would normally not introduce an
incompatibility, except when somebody uses -fno-implicit-templates,
and the template instantiations are in a library produced with an
older compiler (i.e. gcc 2.95). There is a number of problems of that
kind throughout STL: a large number of ordering operators (==, <, ...)
was added.

constant_binary_fun now inherits from _Constant_binary_fun. I don't
think this could cause a problem.

Partial specializations of insert_iterator etc are now provided. This
will break the ABI for applications which pass those iterators around.
In fact, iterators changed so much I can't overlook the changes.

The layout of the internal rope classes changed.

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Benjamin Scherrey]

"Martin v. Loewis" wrote:
> 
> > >> STL 3.2 has one very important advantage (at least in things I'm
> > >> involved in) - it is thread-safe.
> [which class?]
> > <string>, see the thread starting with
> > http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html
> 
> In that case, updating STL won't give you anything: gcc does not use
> <string> from STL. I don't know what the rationale is, but I
> personally prefer the multithreading bug be fixed, instead of using a
> completely different implementation.
<rest snipped>

	Regarding the latest SGI STL, I had been working under the assumption
that it was planned to be included in the next major egcs release
(presumably gcc-2.95). Its my impression that it will break binary
compatibility which seems to be the consensus here as well. I think
its kindof a now or almost never decision isn't it? 2.95 is going to
be a major change and breaking old stuff might well be expected
although screams will certainly ensue regardless. Should we not then
expect that future releases will (almost) never (or certainly not for
a very long time) break binary compatibility? If so then that would
make integration of STL 3.2 something that might never be feasible in
which case we are now choosing to be "left behind" in the SGI tree. Is
that important to egcs developers/users? I really don't know but it
doesn't strike me as a good thing at first impression. The only other
major opportunity for integration I can think of is when the new
c++stdlib is finally integrated but I don't foresee that happening
anytime this year at its present rate of progress.

	I'd appreciate any corrections to my current impressions that others
more knowledgeable than me (that's pretty much all of you) might have
to offer.
	
	thanx & later,

		Ben Scherrey

Re: gcc-2.95 and SGI STL 3.2

[Jeffrey A Law]

  In message < 19990621032446.2159.qmail@deer >you write:
  >   -  gcc 3.0 is an "event" that many people will expect to require
  >      recompiling anyway, so things like a new STL could happen there.
Yup.

  >   -  gcc 2.95 might be "big enough" without the new STL for the gcc
  >      community, especially those users who have not already switched
  >      to EGCS, and thus will see it as the "next" version after 2.8.1.
  >      (I know basically nothing about the STL issues, and therefore have
  >      no opinion on them.)
gcc-2.95 certainly a big jump for those who haven't already switched to the
egcs line of development.  Remember the C++ compiler in gcc-2.8 is old, like
a full 2 years old.  

gcc-2.95 is much less of a jump for those who have been tracking the egcs-1.0,
egcs-1.1 releases.  While I've been told gcc-2.95 will be binary incompatible
with egcs-1.1.2 due to C++ issues, I've actually yet to have any problems 
with linking egcs-1.1.2 C++ libraries with gcc-2.95 C++ code.

  >   -  Someday g77 really needs to break away from libf2c, and define
  >      its own library, libg77.  3.0 would be great for this, but I doubt
  >      it'll happen -- the 0.6 rewrite (which involves the front end,
  >      not the run-time library) is a big-enough task for me now.  That
  >      means libg77 would be a gcc 4.0 item, though possibly we could
  >      decide on it being a 3.X item, since we still speak of g77 being
  >      in "beta".
I think replacing libf2c with libg77 would be a reasonable item to add in a
3.x release if we do not get it into gcc-3.0.

jeff

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>:

>> >> STL 3.2 has one very important advantage (at least in things I'm
>> >> involved in) - it is thread-safe.
> [which class?]
>> <string>, see the thread starting with
>> http://egcs.cygnus.com/ml/egcs-bugs/1999-04/msg00771.html

> In that case, updating STL won't give you anything: gcc does not use
> <string> from STL. I don't know what the rationale is,

The native g++ <string> uses refcounting.  The SGI STL <string> always
does a deep copy.

Re: gcc-2.95 and SGI STL 3.2

[Martin v. Loewis]

> Perhaps this should be something for gcc-2.95.1?

Before making that change, it should be well-established that
integrating STL 3.2 wouldn't break binary compatibility with gcc 2.95.
Given past experience, it likely will (no, I haven't analyzed this at
all).

What important new features will STL 3.2 give us, anyway?

Regards,
Martin

Re: gcc-2.95 and SGI STL 3.2

[Tim Waugh]

On 21 Jun 1999, Steinar Bang wrote:

> The native g++ <string> uses refcounting.  The SGI STL <string> always
> does a deep copy.

I don't think refcounting actually helps much with strings -- you have to
do a deep copy whenever the data is accessed anyway (even read: think
'string s="str",t; char &c=s[0];').

Tim.
*/

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> dvv@dvv.ru (Dima Volodin):

> On Mon, 21 Jun 1999 09:09:42 +0100 (GMT), you wrote:
>> On 21 Jun 1999, Steinar Bang wrote:
>> 
>>> The native g++ <string> uses refcounting.  The SGI STL <string> always
>>> does a deep copy.

>> I don't think refcounting actually helps much with strings -- you
>> have to do a deep copy whenever the data is accessed anyway (even
>> read: think 'string s="str",t; char &c=s[0];').

> Besides, in a multi-threaded environment, refcounting requires an
> extra mutex,...

There's an article by Herb Sutter in the june 1999 issue of the C/C++
Users Journal
        http://www.cuj.com/archive/1706/
(no online version of the article, unfortunately), that addresses
refcounting in a multithreaded world.  It uses something called
"atomic integer operations" to do thread-safe refcounting at a lower
cost than mutex operations.

But as I understand it, these operations may not be available on all
systems, and if they are, may have different interfaces.

Re: gcc-2.95 and SGI STL 3.2

[mark]

I think would be inappropriate to integrate STL 3.2 now.  We are
supposed to be in critical bug-fix mode, putting in changes which:

  o Fix serious problems.
  o Clearly to do not break things.

It's not clear that STL 3.2 meets either criterion, even though it
does fix some bugs.

I don't think this is appropriate for a dot-release either.  There we
should be doing more serious bug-fixing, and we shouln't take chances
with binary compatibility, except to fix bugs.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: gcc-2.95 and SGI STL 3.2

[Steinar Bang]

>>>>> craig@jcb-sc.com:

> Just to add my two cents, FWIW:
>   -  gcc 3.0 is an "event" that many people will expect to require
>      recompiling anyway, so things like a new STL could happen there.

gcc 3.0 will presumably use libstdc++-v3, which currently includes SGI 
STL 3.2:
        http://sourceware.cygnus.com/libstdc++/faq/index.html#5_3

Re: gcc-2.95 and SGI STL 3.2

[Joe Buck]

> > Perhaps this should be something for gcc-2.95.1?
> 
> Before making that change, it should be well-established that
> integrating STL 3.2 wouldn't break binary compatibility with gcc 2.95.
> Given past experience, it likely will (no, I haven't analyzed this at
> all).

That's a factor that makes it really too bad that we didn't manage to
make the change for gcc-2.95: it then means we can't make the change
for later minor releases either.

> What important new features will STL 3.2 give us, anyway?

Performance improvements and bug fixes, principally.  See
http://www.sgi.com/Technology/STL/whats_new.html

Unfortunately, upgrading egcs/gcc to a new STL is not trivial, as SGI
is providing some classes that we are also providing, so it takes a bit
of care to figure out exactly what to leave out and then to make sure
that this doesn't break anything.

Re: gcc-2.95 and SGI STL 3.2

[Joe Buck]

> On 21 Jun 1999, Steinar Bang wrote:
> 
> > The native g++ <string> uses refcounting.  The SGI STL <string> always
> > does a deep copy.
> 
> I don't think refcounting actually helps much with strings -- you have to
> do a deep copy whenever the data is accessed anyway (even read: think
> 'string s="str",t; char &c=s[0];').

You are not correct, you don't have to do a deep copy whenever the data
is accessed.  On a writable string, using begin(), end(), or [] on a
string with multiple references will require a deep copy.  However, those
same operations on a const string& will not require a copy, and
furthermore there are many other ways to access string data that don't
need a copy.  So in practice, programs that use strings a lot typically
have many references to the same string representation object (including
most of what I've written).  Switching to the SGI scheme would have
a substantial cost.

gcc-2.95 and SGI STL 3.2

[Ryszard Kabatek]

The source of gcc-2.95 is now frozen (June 15, 1999. Critical Bug Freeze Date),
but it does not contain the SGI STL 3.2.

Is it a final decision?

Ryszard Kabatek
Martin-Luther University Halle-Wittenberg, Department of Physical Chemistry
Geusaer Str. 88, 06217 Merseburg, Germany
Tel. +49 3461 46 2487 (2466) Fax. +49 3461 46 2129

Re: gcc-2.95 and SGI STL 3.2

[Jason Merrill]

>>>>> Ryszard Kabatek <rysio@rumcajs.chemie.uni-halle.de> writes:

 > Are there any technical problems with the integration of the 3.2 version? 

No, just that nobody has taken the initiative.

Jason

Re: gcc-2.95 and SGI STL 3.2

[Mike Stump]

> From: Jason Merrill <jason@cygnus.com>
> Date: 20 Jun 1999 21:55:14 -0700

> I don't feel strongly about integrating 3.2 now; I think it's a
> mistake that we didn't do it before.  I had been waiting for Ulrich
> to take the initiative.  I would be opposed to doing it in a dot
> release, as it would break binary compatibility.

I'm in general agreement.  I think it is just too late now (all big
things and even quite a few small things tend to shoot release quality
in the foot if incorporated just before before release).  Would have
been nice if it had been in the tree for the past few months, oh well.

Re: gcc-2.95 and SGI STL 3.2

[Phil Edwards]

> In that case, updating STL won't give you anything: gcc does not use
> <string> from STL. I don't know what the rationale is, but I
> personally prefer the multithreading bug be fixed, instead of using a
> completely different implementation.

The SGI <string> is, upon examination, essentially a vector<char>, with
no major optimizations.  I think that Ye Olde Bastring.cc Implementation
that's in the current egcs releases is not being worked on anymore,
since all the attention is going to...

> As for libstdc++ v3: It seems there is yet another string
> implementation, (apparently) contributed by Nathan Myers.

...this one.  It does COW buffer sharing and reference counting.  IIRC,
some of the buffer issues are still being tweaked, but I couldn't
speak authoritatively on the MT status.



(If you reply to the list, please don't cc another copy to me.  Thanks!)
Phil

Re: gcc-2.95 and SGI STL 3.2

[Mike Stump]

> From: Jason Merrill <jason@cygnus.com>
> Date: 20 Jun 1999 21:55:14 -0700

> I don't feel strongly about integrating 3.2 now; I think it's a
> mistake that we didn't do it before.  I had been waiting for Ulrich
> to take the initiative.  I would be opposed to doing it in a dot
> release, as it would break binary compatibility.

I'm in general agreement.  I think it is just too late now (all big
things and even quite a few small things tend to shoot release quality
in the foot if incorporated just before before release).  Would have
been nice if it had been in the tree for the past few months, oh well.

Re: gcc-2.95 and SGI STL 3.2

[Phil Edwards]

> In that case, updating STL won't give you anything: gcc does not use
> <string> from STL. I don't know what the rationale is, but I
> personally prefer the multithreading bug be fixed, instead of using a
> completely different implementation.

The SGI <string> is, upon examination, essentially a vector<char>, with
no major optimizations.  I think that Ye Olde Bastring.cc Implementation
that's in the current egcs releases is not being worked on anymore,
since all the attention is going to...

> As for libstdc++ v3: It seems there is yet another string
> implementation, (apparently) contributed by Nathan Myers.

...this one.  It does COW buffer sharing and reference counting.  IIRC,
some of the buffer issues are still being tweaked, but I couldn't
speak authoritatively on the MT status.



(If you reply to the list, please don't cc another copy to me.  Thanks!)
Phil