Plans for 3.0.4 ?

Plans for 3.0.4 ?

[Robert Boehne]

Hello,

Recently Jason Merrill checked in patches to fix PR4122 before
which gcc 3.x was unusable for our software, so having another
release with these patches included would be nice.

What (if any) are the plans for a 3.0.4 release of gcc?

Thanks,

Robert

-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  rboehne@ricardo-us.com

Re: Plans for 3.0.4 ?

[David Edelsohn]

>>>>> Robert Boehne writes:

Robert> Recently Jason Merrill checked in patches to fix PR4122 before
Robert> which gcc 3.x was unusable for our software, so having another
Robert> release with these patches included would be nice.

Robert> What (if any) are the plans for a 3.0.4 release of gcc?

	gcc-3.0.4 is scheduled for two months after the last release --
February 2002.

David

Re: Plans for 3.0.4 ?

[Craig Rodrigues]

On Mon, Jan 14, 2002 at 11:06:56AM -0500, David Edelsohn wrote:
> 
> 	gcc-3.0.4 is scheduled for two months after the last release --
> February 2002.

Where was the announcement for this posted?

I didn't see it mentioned here:
http://gcc.gnu.org/ml/gcc-announce/2001/msg00006.html

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

Or should it just be understood that new releases on
the branch will come out every two months?

Thanks. 
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: Plans for 3.0.4 ?

[Mark Mitchell]

> What (if any) are the plans for a 3.0.4 release of gcc?

I've been deliberately noncommittal, but it's time to commit, I guess.

So, this is a poll: how many people feel that a 3.0.4 release
would be valuable?

Your RM,

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

Re: Plans for 3.0.4 ?

[Phil Blundell]

On Wed, 2002-01-16 at 07:07, Mark Mitchell wrote:
> > What (if any) are the plans for a 3.0.4 release of gcc?
> 
> I've been deliberately noncommittal, but it's time to commit, I guess.
> 
> So, this is a poll: how many people feel that a 3.0.4 release
> would be valuable?

It would be nice to see a 3.0 release that could at least bootstrap
fully on arm-linux (see PR 5209, for example).  I guess that counts as a
"yes" from me.

p.

Re: Plans for 3.0.4 ?

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| > What (if any) are the plans for a 3.0.4 release of gcc?
| 
| I've been deliberately noncommittal, but it's time to commit, I guess.
| 
| So, this is a poll: how many people feel that a 3.0.4 release
| would be valuable?

V3 has already expressed interests in such a release.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: Plans for 3.0.4 ?

[Paolo Carlini]

Gabriel Dos Reis wrote:

> Mark Mitchell <mark@codesourcery.com> writes:
>
> | > What (if any) are the plans for a 3.0.4 release of gcc?
> |
> | I've been deliberately noncommittal, but it's time to commit, I guess.
> |
> | So, this is a poll: how many people feel that a 3.0.4 release
> | would be valuable?
>
> V3 has already expressed interests in such a release.

Gaby probably hints to libstdc++/5037, among others.

I would like to add that we have also a triplicate report,
libstdc++/5292/5181/3272, fixed only in the mainline, which could be backported
rather easily, IMHO.

Cheers,
Paolo.

Re: Plans for 3.0.4 ?

[Joe Buck]

Re 3.0.4, Paolo writes:

> Gaby probably hints to libstdc++/5037, among others.
> 
> I would like to add that we have also a triplicate report,
> libstdc++/5292/5181/3272, fixed only in the mainline, which could be backported
> rather easily, IMHO.

There's a constraint on any libstdc++ backport fixes: they can't break
the ABI (code compiled by 3.0.3 must link against 3.0.4 libraries and
vice versa).  But as long as that criterion is met, fixes can be
backported.

Re: Plans for 3.0.4 ?

[Paolo Carlini]

Joe Buck wrote:

> Re 3.0.4, Paolo writes:
>
> > Gaby probably hints to libstdc++/5037, among others.
> >
> > I would like to add that we have also a triplicate report,
> > libstdc++/5292/5181/3272, fixed only in the mainline, which could be backported
> > rather easily, IMHO.
>
> There's a constraint on any libstdc++ backport fixes: they can't break
> the ABI (code compiled by 3.0.3 must link against 3.0.4 libraries and
> vice versa).

I see.

>  But as long as that criterion is met, fixes can be
> backported.

The fix for libstdc++/5037 is already in the branch.
As regards libstdc++/5292/5181/3272, I'm convinced that the fix currently present in
the mainline (http://gcc.gnu.org/ml/gcc-cvs/2001-06/msg00862.html) does *not* break
the ABI.

Benjamin?

Cheers,
Paolo.

Re: Plans for 3.0.4 ?

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> So, this is a poll: how many people feel that a 3.0.4 release
Mark> would be valuable?

	I would definitely like a 3.0.4 release so that there will be a
GCC 3.0 release that works on AIX.

Thanks, David

Re: Plans for 3.0.4 ?

[Bradley D. LaRonde]

----- Original Message -----
From: "Mark Mitchell" <mark@codesourcery.com>
To: <rboehne@ricardo-us.com>; <gcc@gcc.gnu.org>
Sent: Wednesday, January 16, 2002 2:07 AM
Subject: Re: Plans for 3.0.4 ?


> > What (if any) are the plans for a 3.0.4 release of gcc?
>
> I've been deliberately noncommittal, but it's time to commit, I guess.
>
> So, this is a poll: how many people feel that a 3.0.4 release
> would be valuable?

I believe that the mips arch really needs a 3.0.4 release to get the -mtune
stuff right (which became broken in 3.0.3).

Regards,
Brad

Re: Plans for 3.0.4 ?

[Mark Mitchell]

--On Wednesday, January 16, 2002 11:08:07 AM -0500 "Bradley D. LaRonde" 
<brad@ltc.com> wrote:

> ----- Original Message -----
> From: "Mark Mitchell" <mark@codesourcery.com>
> To: <rboehne@ricardo-us.com>; <gcc@gcc.gnu.org>
> Sent: Wednesday, January 16, 2002 2:07 AM
> Subject: Re: Plans for 3.0.4 ?
>
>
>> > What (if any) are the plans for a 3.0.4 release of gcc?
>>
>> I've been deliberately noncommittal, but it's time to commit, I guess.
>>
>> So, this is a poll: how many people feel that a 3.0.4 release
>> would be valuable?
>
> I believe that the mips arch really needs a 3.0.4 release to get the
> -mtune stuff right (which became broken in 3.0.3).

OK, there's clearly interest.

When you (and everyone else) say "There needs to be a release so that
my platform works" is it already the case that your platform works
with the branch sources, or are you really saying "First, someone should
fix my platform and then there should be a release with the fix?"

Yours,

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

Re: Plans for 3.0.4 ?

[Bradley D. LaRonde]

----- Original Message -----
From: "Mark Mitchell" <mark@codesourcery.com>
To: "Bradley D. LaRonde" <brad@ltc.com>; <gcc@gcc.gnu.org>
Sent: Wednesday, January 16, 2002 11:51 AM
Subject: Re: Plans for 3.0.4 ?


> --On Wednesday, January 16, 2002 11:08:07 AM -0500 "Bradley D. LaRonde"
> <brad@ltc.com> wrote:
>
> > ----- Original Message -----
> > From: "Mark Mitchell" <mark@codesourcery.com>
> > To: <rboehne@ricardo-us.com>; <gcc@gcc.gnu.org>
> > Sent: Wednesday, January 16, 2002 2:07 AM
> > Subject: Re: Plans for 3.0.4 ?
> >
> >
> >> > What (if any) are the plans for a 3.0.4 release of gcc?
> >>
> >> I've been deliberately noncommittal, but it's time to commit, I guess.
> >>
> >> So, this is a poll: how many people feel that a 3.0.4 release
> >> would be valuable?
> >
> > I believe that the mips arch really needs a 3.0.4 release to get the
> > -mtune stuff right (which became broken in 3.0.3).
>
> OK, there's clearly interest.
>
> When you (and everyone else) say "There needs to be a release so that
> my platform works" is it already the case that your platform works
> with the branch sources, or are you really saying "First, someone should
> fix my platform and then there should be a release with the fix?"

In my case, 3.0.2 worked fine (for me, ymmv), 3.0.3 introduced the -mtune
brokenness, and the 3.0 branch remains broken to the best of my knowledge.
I flagged the problem the arch maintainer Eric Christopher.  Maybe I should
file a formal bug report?

Regards,
Brad

Re: Plans for 3.0.4 ?

[Mark Mitchell]

> In my case, 3.0.2 worked fine (for me, ymmv), 3.0.3 introduced the -mtune
> brokenness, and the 3.0 branch remains broken to the best of my knowledge.
> I flagged the problem the arch maintainer Eric Christopher.  Maybe I
> should file a formal bug report?

Or produce a patch, or contact the person who introduced the regression
and ask them to fix it.

The point is that I am happy to coordinate a 3.0.4 release -- but I
cannot fix all the bugs that might be out there. :-(

Let's follow the following procedure:

1. If you would like to see a 3.0.4 release, please send me mail
   privately.  Explain what bugs have already been fixed on the
   branch that are important to you.

2. If there are bugs that have not already been fixed, but which
   are regressions in 3.0.3 relative to previous releases, please
   file GNATS bug reports, and send me the PR number with your mail.

I will then coordinate this information and get a release out.

Yours,

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

Re: Plans for 3.0.4 ?

[Mark Mitchell]

> I flagged the problem the arch maintainer Eric Christopher.  Maybe I
> should file a formal bug report?

Yes, definitely.  Then, please send me the PR number.

Thank you,

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

Re: Plans for 3.0.4 ?

[Craig Rodrigues]

On Tue, Jan 15, 2002 at 11:07:19PM -0800, Mark Mitchell wrote:
> 
> So, this is a poll: how many people feel that a 3.0.4 release
> would be valuable?

I didn't know that a 3.0.4 release was coming, because
I did not see it mentioned in the Development Plan:
http://gcc.gnu.org/develop.html

Consequently, I haven't been checking any fixes onto branch, 
just mainline.

If we release 3.0.4 we should:
- make a list of bugs that should be fixed for 3.0.4, preferably
  referenced by PR, such as PR 4122.

  Does PR 3145.patch, which affects KDE, now qualify for 3.0.4?

- figure out what changes from 3.0.3 need to be merged from
  mainline, if any
- in the 3.0.4 release announcement, mention what bugs have been
  fixed since 3.0.3 (encourage people to reference PR's fixed 
  in the ChangeLog)
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: Plans for 3.0.4 ?

[Joe Buck]

Craig Rodrigues writes:

> If we release 3.0.4 we should:
> - make a list of bugs that should be fixed for 3.0.4, preferably
>   referenced by PR, such as PR 4122.

Agreed.  Furthermore I don't think we can fix a bug in 3.0.4 that
isn't already fixed in the trunk or that can't be fixed almost
immediately (Mark can set the deadline, but I'd anticipate a very
short window).

>   Does PR 3145.patch, which affects KDE, now qualify for 3.0.4?

This is a pretty scary-looking patch: more than 100k.  How extensively has
it been tested?  What are the binary compatibility issues?  (caring only
about binary compatibility for code that 3.0.3 compiles correctly, of
course).  Is this fix required to get KDE working reasonably, or can
the problem be coded around?

> - figure out what changes from 3.0.3 need to be merged from
>   mainline, if any
> - in the 3.0.4 release announcement, mention what bugs have been
>   fixed since 3.0.3 (encourage people to reference PR's fixed 
>   in the ChangeLog)

Yes.

Re: Plans for 3.0.4 ?

[Mark Mitchell]

>>   Does PR 3145.patch, which affects KDE, now qualify for 3.0.4?
>
> This is a pretty scary-looking patch: more than 100k.  How extensively has
> it been tested?  What are the binary compatibility issues?  (caring only
> about binary compatibility for code that 3.0.3 compiles correctly, of
> course).  Is this fix required to get KDE working reasonably, or can
> the problem be coded around?

I don't want to try to put this in a 3.0 series release.  I think we
have to wait for 3.1, which really isn't that far away at this point.
I'll have a lot more confidence about the change in that context.

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

Re: Plans for 3.0.4 ?

[Craig Rodrigues]

On Wed, Jan 16, 2002 at 02:46:39AM -0800, Mark Mitchell wrote:
> 
> I don't want to try to put this in a 3.0 series release.  I think we
> have to wait for 3.1, which really isn't that far away at this point.
> I'll have a lot more confidence about the change in that context.

According this this:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01525.html

The patch is already in mainline, so this may be a moot point.

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: Plans for 3.0.4 ?

[Mark Mitchell]

--On Wednesday, January 16, 2002 02:13:58 PM -0500 Craig Rodrigues 
<rodrigc@mediaone.net> wrote:

> http://gcc.gnu.org/ml/gcc-patches/2001-11/msg01525.html

That's what I mean; this patch is already on the mainline, where
it's getting tested in that context, and it will therefore show
up in 3.1.  3.0.4 will only be two months before 3.1.

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

Re: Plans for 3.0.4 ? (Re: new PR libstdc++/5432)

[Andrew Pollard]

Mark Mitchell <mark@codesourcery.com> wrote:

>> What (if any) are the plans for a 3.0.4 release of gcc?

> I've been deliberately noncommittal, but it's time to commit, I guess.
>
> So, this is a poll: how many people feel that a 3.0.4 release
> would be valuable?

I would like to see a 3.0.4 release, hopefully fixing the libstdc++/5432
report that I have just submitted (related to libstdc++/5347 and
libstdc++/5037 - multithreading issues on multiprocessor machines).

I attempted to attach a test program and a tentative patch to the problem
report, but only the patch made it :-(

I'm including the test program here in the hope that someone with the right
access can update the gnats report to include this as well....

I'm also including the patch here (which attempts to address some of the
"XXX MT" issues in the libstdc++ source code) which seems to 'fix' the
problems...

main.cxx
------------------------------------------------------------------------------
#include <pthread.h>
#include <sstream>

const size_t num_threads = 4;

extern "C" {
    static void*
    threadFunc(void*)
    {
        for (size_t i = 0; i < 10000; ++i) {
            std::stringstream str;
        }

        pthread_exit(0);

        return(0);
    }
}

int
main()
{
    pthread_t threads[num_threads];

#if !defined(__linux__)
    thr_setconcurrency(num_threads);
#endif

    for (size_t i = 0; i < num_threads; ++i) {
        pthread_create(&(threads[i]), 0, threadFunc, 0);
    }

    for (size_t i = 0; i < num_threads; ++i) {
        pthread_join(threads[i], 0);
    }

    pthread_exit(0);

    return (0);
}
------------------------------------------------------------------------------

patch
------------------------------------------------------------------------------
Index: include/bits/ios_base.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/ios_base.h,v
retrieving revision 1.8.2.3
diff -u -r1.8.2.3 ios_base.h
--- ios_base.h	2001/06/06 01:39:00	1.8.2.3
+++ ios_base.h	2002/01/17 12:53:38
@@ -36,6 +36,8 @@
 
 #pragma GCC system_header
 
+#include <bits/atomicity.h>
+
 namespace std
 {
   // The following definitions of bitmask types are enums, not ints,
@@ -239,17 +241,17 @@
       _Callback_list* 		_M_next;
       ios_base::event_callback 	_M_fn;
       int 			_M_index;
-      int 			_M_refcount;  // 0 means one reference.
+      _Atomic_word		_M_refcount;  // 0 means one reference.
     
       _Callback_list(ios_base::event_callback __fn, int __index, 
 		     _Callback_list* __cb)
       : _M_next(__cb), _M_fn(__fn), _M_index(__index), _M_refcount(0) { }
       
       void 
-      _M_add_reference() { ++_M_refcount; } // XXX MT
+      _M_add_reference() { __atomic_add(&_M_refcount, 1); } // XXX MT
       
       int 
-      _M_remove_reference() { return _M_refcount--; }  // 0 => OK to delete
+      _M_remove_reference() { return __exchange_and_add(&_M_refcount, -1); }  // 0 => OK to delete
     };
 
      _Callback_list*  	_M_callbacks;
Index: include/bits/localefwd.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/localefwd.h,v
retrieving revision 1.11.2.3
diff -u -r1.11.2.3 localefwd.h
--- localefwd.h	2001/05/14 19:49:03	1.11.2.3
+++ localefwd.h	2002/01/17 12:53:38
@@ -43,6 +43,8 @@
 #include <bits/std_cctype.h>	// For isspace, etc.
 #include <bits/functexcept.h>
 
+#include <bits/atomicity.h>
+
 namespace std
 {
   // NB: Don't instantiate required wchar_t facets if no wchar_t support.
@@ -307,7 +309,7 @@
 
   private:
     // Data Members.
-    size_t 				_M_references;
+    _Atomic_word			_M_references;
     __vec_facet* 			_M_facets;
     string 				_M_names[_S_num_categories];
     __c_locale				_M_c_locale;
@@ -321,12 +323,12 @@
 
     inline void 
     _M_add_reference() throw()
-    { ++_M_references; }  // XXX MT
+    { __atomic_add(&_M_references, 1); }  // XXX MT
 
     inline void 
     _M_remove_reference() throw()
     {
-      if (_M_references-- == 0)  // XXX MT
+      if (__exchange_and_add(&_M_references, -1) == 0)  // XXX MT
 	{
 	  try 
 	    { delete this; } 
@@ -394,7 +396,7 @@
     _S_destroy_c_locale(__c_locale& __cloc);
 
   private:
-    size_t _M_references;
+    _Atomic_word _M_references;
 
     void 
     _M_add_reference() throw();
@@ -428,7 +430,7 @@
     mutable size_t 	_M_index;
 
     // Last id number assigned
-    static size_t 	_S_highwater;   
+    static _Atomic_word 	_S_highwater;   
 
     void 
     operator=(const id&);  // not defined
Index: src/ios.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/ios.cc,v
retrieving revision 1.14.4.2
diff -u -r1.14.4.2 ios.cc
--- ios.cc	2001/06/06 01:39:01	1.14.4.2
+++ ios.cc	2002/01/17 12:53:38
@@ -36,6 +36,8 @@
 #include <bits/std_istream.h>
 #include <bits/std_fstream.h>
 
+#include <bits/atomicity.h>
+
 namespace std 
 {
   // Extern declarations for global objects in src/globals.cc.
@@ -216,8 +218,8 @@
   {
     // XXX MT
     // XXX should be a symbol. (Reserve 0..3 for builtins.)
-    static int top = 4; 
-    return top++;
+    static _Atomic_word top = 4; 
+    return __exchange_and_add(&top, 1);
   }
 
   // 27.4.2.5  iword/pword storage
Index: src/locale.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/locale.cc,v
retrieving revision 1.28.2.5
diff -u -r1.28.2.5 locale.cc
--- locale.cc	2001/12/11 08:01:24	1.28.2.5
+++ locale.cc	2002/01/17 12:53:39
@@ -41,6 +41,8 @@
 # include <bits/std_cwctype.h>     // for towupper, etc.
 #endif
 
+#include <bits/atomicity.h>
+
 namespace std 
 {
   // Definitions for static const data members of locale.
@@ -68,7 +70,7 @@
 #endif
 
   // Definitions for static const data members of locale::id
-  size_t locale::id::_S_highwater;  // init'd to 0 by linker
+  _Atomic_word locale::id::_S_highwater;  // init'd to 0 by linker
 
   // Definitions for static const data members of locale::_Impl
   const locale::id* const
@@ -445,6 +447,9 @@
   locale::classic()
   {
     static locale* __classic_locale;
+    static _STL_mutex_lock __lock __STL_MUTEX_INITIALIZER;
+    _STL_auto_lock __auto(__lock);
+
     // XXX MT
     if (!_S_classic)
       {
@@ -523,15 +528,13 @@
   void  
   locale::facet::
   _M_add_reference() throw()
-  { ++_M_references; }                     // XXX MT
+  { __atomic_add(&_M_references, 1); }                     // XXX MT
 
   void  
   locale::facet::
   _M_remove_reference() throw()
   {
-    if (_M_references)
-      --_M_references;
-    else
+    if (__exchange_and_add(&_M_references, -1) == 0)
       {
         try 
 	  { delete this; }  // XXX MT
Index: src/localename.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/localename.cc,v
retrieving revision 1.12.2.2
diff -u -r1.12.2.2 localename.cc
--- localename.cc	2001/05/14 19:49:15	1.12.2.2
+++ localename.cc	2002/01/17 12:53:39
@@ -173,7 +173,7 @@
       {
 	size_t& __index = __idp->_M_index;
 	if (!__index)
-	  __index = ++locale::id::_S_highwater;  // XXX MT
+	  __index = 1 + __exchange_and_add(&locale::id::_S_highwater, 1);  // XXX MT
 	
 	if (__index >= _M_facets->size())
 	  _M_facets->resize(__index + 1, 0);  // might throw
------------------------------------------------------------------------------

Andrew.
--
 Andrew Pollard, ASI/Brooks Automation  | home: andrew@andypo.net
670 Eskdale Road, Winnersh Triangle, UK | work: Andrew.Pollard@brooks.com
 Tel/Fax:+44 (0)118 9215603 / 9215660   | http://www.andypo.net

Re: Plans for 3.0.4 ?

[Richard B. Kreckel]

Hi,

On Tue, 15 Jan 2002, Mark Mitchell wrote:
> > What (if any) are the plans for a 3.0.4 release of gcc?
> 
> I've been deliberately noncommittal, but it's time to commit, I guess.
> 
> So, this is a poll: how many people feel that a 3.0.4 release
> would be valuable?

Well, I would definitely appreciate one.


Oh, and I would even more appreciate one which reverts this:

> Mon Jul 16 19:57:19 2001  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>
>
>   * config/alpha/osf.h (ASM_OUTPUT_WEAK_ALIAS, ASM_WEAKEN_LABEL,
>   HANDLE_SYSV_PRAGMA): Define.
>   * mips-tfile.c (add_ext_symbol): Pass complete symbol ptr, inline
>   previous args.
>   (copy_object): Caller changed.
>
>   testsuite:
>   * g++.old-deja/g++.pt/static3.C: Removed alpha*-*-osf* XFAIL.
>   g++.old-deja/g++.pt/static6.C: Likewise.
>   * lib/target-supports.exp (check_weak_available): alpha*-*-osf*
>   supports weak symbols.

We still get complaints from people that CLN [*] does not compile on Tru64
5.1 and I have repeatedly pointed out that this is due to above patch
which showed up in the 3.0.1 release -- without ever getting any response
from the author.  Maybe that patch is just broken or incomplete?

Regards
    -richy.

[*] <http://www.gnu.org/directory/CLN.html>
-- 
Richard B. Kreckel
<Richard.Kreckel@Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>

Re: Plans for 3.0.4 ?

[Mark Mitchell]

> We still get complaints from people that CLN [*] does not compile on Tru64
> 5.1 and I have repeatedly pointed out that this is due to above patch
> which showed up in the 3.0.1 release -- without ever getting any response
> from the author.  Maybe that patch is just broken or incomplete?

Please file a GNATS PR about this issue and send me the PR number assigned
so that I can track this information.

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

Re: Plans for 3.0.4 ?

[Benjamin Kosnik]

> As regards libstdc++/5292/5181/3272, I'm convinced that the fix
> currently present in the mainline
> (http://gcc.gnu.org/ml/gcc-cvs/2001-06/msg00862.html) does *not* break
> the ABI.

Paolo this patch is fine for 3.0.4. If you want to bring it over to
the branch please do so.

-benjamin