[Bug libstdc++/16248] New: recent concurrence.h chanes breaks mingw bootstrap

[Bug libstdc++/16248] New: recent concurrence.h chanes breaks mingw bootstrap

[bothner at gcc dot gnu dot org]

The problem is that we get this case in concurrence.h:

// Implies __GTHREAD_MUTEX_INIT_FUNCTION
#  define __glibcxx_mutex_define_initialized(NAME) \
__gthread_mutex_t NAME; \
__gthread_once_t NAME ## _once = __GTHREAD_ONCE_INIT; \
void NAME ## _init() { __GTHREAD_MUTEX_INIT_FUNCTION(&NAME); }
# define __glibcxx_mutex_lock(NAME) \
__gthread_once(&NAME ## _once, NAME ## _init); \
__gthread_mutex_lock(&NAME)

The class lock uses the macro __glibcxx_mutex_lock.
This makes reference to device_once and device_init.

/home/bothner/GNU/MinGW/build/crossgcc_build/gcc/xgcc -shared-libgcc
-B/home/bothner/GNU/MinGW/build/crossgcc_build/gcc/ -nostdinc++
-L/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/src
-L/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/src/.libs
-B/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/bin/
-B/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/lib/ -isystem
/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/include -isystem
/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/sys-include
-I/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32
-I/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include
-I/home/bothner/GNU/MinGW/gcc/libstdc++-v3/libsupc++ -O2 -g -g
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -c
/home/bothner/GNU/MinGW/gcc/libstdc++-v3/src/allocator.cc -o allocator.o
In file included from
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h:54,
                 from /home/bothner/GNU/MinGW/gcc/libstdc++-v3/src/allocator.cc:37:
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:
In constructor `__gnu_cxx::lock::lock(__gthread_mutex_t&)':
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:76:
error: `device_once' was not declared in this scope
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:76:
error: `device_init' was not declared in this scope
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:76:
warning: unused variable 'device_once'
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:76:
warning: unused variable 'device_init'
make[3]: *** [allocator.lo] Error 1

The problem is these are never defined, as there is no
invocation of the macro __glibcxx_mutex_define_initialized.
I don't see how to fix the lock class to invoke the macro,
since the macro needs to define a C-style function - for
each lock *instance*, which isn't easy to do. 

The problem would be for any target that defines __GTHREADS
but not __GTHREAD_MUTEX_INIT - i.e. that uses
__GTHREAD_MUTEX_INIT_FUNCTION.

-- 
           Summary: recent concurrence.h chanes breaks mingw bootstrap
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: libstdc++
        AssignedTo: bkoz at constant dot com
        ReportedBy: bothner at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal
            Summary|recent concurrence.h chanes |[3.5 Regression] recent
                   |breaks mingw bootstrap      |concurrence.h chanes breaks
                   |                            |mingw bootstrap
   Target Milestone|---                         |3.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[membar at gcc dot gnu dot org]

------- Additional Comments From membar at gcc dot gnu dot org  2004-06-29 06:20 -------
I proposed a patch here:

http://gcc.gnu.org/ml/libstdc++/2004-06/msg00359.html

...but don't have a non-hacked-up mainline anymore. If no one gets to this 
first, I can look at this in a couple of days.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-29 06:26 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |build, patch
   Last reconfirmed|0000-00-00 00:00:00         |2004-06-29 06:26:06
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[per at bothner dot com]

------- Additional Comments From per at bothner dot com  2004-06-29 18:16 -------
Subject: Re:  [3.5 Regression] recent concurrence.h chanes
 breaks mingw bootstrap

membar at gcc dot gnu dot org wrote:

> ------- Additional Comments From membar at gcc dot gnu dot org  2004-06-29 06:20 -------
> I proposed a patch here:
> 
> http://gcc.gnu.org/ml/libstdc++/2004-06/msg00359.html
> 
> ...but don't have a non-hacked-up mainline anymore. If no one gets to this 
> first, I can look at this in a couple of days.

I don't think poiter-vs-reference is the issue.  The question is who
is response for calling the __GTHREAD_MUTEX_INIT_FUNCTION:  Is it done
eagerly during mutex creation, in__glibcxx_mutex_define_initialized,
or is it done lazily, the first time the lock is acquired?  The current
CVS code code attampts to do the latter; your patch (as far as I can
tell) ends up doing neither, which I don't think can be right.

I.e. when does CreateSemaphore get called?  If it gets called eagerly,
then we don't need the "once" functionality, and something like this
should work:

class __glibcxx_mutex : public __gthread_mutex_t
{
   __glibcxx_mutex () { __GTHREAD_MUTEX_INIT_FUNCTION(this); }
};
#  define __glibcxx_mutex_define_initialized(NAME) \
__glibcxx_mutex NAME
# define __glibcxx_mutex_lock(NAME) \
__gthread_mutex_lock(&NAME)

If we want CreateSemaphore to be called lazily things get more
difficult.  We can't use teh existing __gthread_once function,
since that calls a global zero-parameter function.  We can however
crerate a variation of __gthread_once that calls a one-parameter
function, or invokes an object method.  However, that requires
some more extensive changes.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[membar at gcc dot gnu dot org]

------- Additional Comments From membar at gcc dot gnu dot org  2004-06-29 18:33 -------
Hi Per,

The pointer vs. reference thing is just some beautification which my itchy 
fingers couldn't help doing - I agree that it's not germane to the problem at 
hand.

If you look at the comments for the class in question (and also all occurrences 
of the code that use this class), you see that the mutex is assumed to already 
be initialized - it's sufficient to lock the mutex without doing any 
initialization on it. That's why I created and used a new macro called 
__glibcxx_mutex_lock_noinit for this purpose.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[per at bothner dot com]

------- Additional Comments From per at bothner dot com  2004-06-29 18:46 -------
Subject: Re:  [3.5 Regression] recent concurrence.h chanes
 breaks mingw bootstrap

membar at gcc dot gnu dot org wrote:


> If you look at the comments for the class in question (and also all occurrences 
> of the code that use this class), you see that the mutex is assumed to already 
> be initialized - it's sufficient to lock the mutex without doing any 
> initialization on it. That's why I created and used a new macro called 
> __glibcxx_mutex_lock_noinit for this purpose.

The mutex is *assumed* to be initialized, but it isn't until
__GTHREAD_MUTEX_INIT_FUNCTION is called.  And your patch fails
to do that.  The macro __glibcxx_mutex_define_initialized
defines a function NAME##once that calls __GTHREAD_MUTEX_INIT_FUNCTION
but no-body ever calls NAME##once.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[membar at gcc dot gnu dot org]

------- Additional Comments From membar at gcc dot gnu dot org  2004-06-29 20:34 -------
AAARGH! You're right in your analyses for all the reasons you mentioned.

The "proper" solution would be to modify gthread_once, like you mentioned. But 
that seems too far-reaching. As a compromise, why not answer a hack with a 
hack?:

2004-06-29  Mohan Embar  <gnustuff@thisiscool.com>

	* include/bits/concurrence.h (__glibcxx_mutex): New macro.
	(__glibcxx_mutex_parms): New macro.
	(__gnu_cxx::lock): Change device field from a pointer to a
	reference; use new __glibcxx_mutex and __glibcxx_mutex_parms
	macros in constructor.
	* src/locale_init.cc (locale::locale): Use __glibcxx_mutex
	macro.
	(locale::global): Likewise.

Index: include/bits/concurrence.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/include/bits/concurrence.h,v
retrieving revision 1.5
diff -u -2 -r1.5 concurrence.h
--- include/bits/concurrence.h	25 Jun 2004 16:36:13 -0000	1.5
+++ include/bits/concurrence.h	29 Jun 2004 20:26:58 -0000
@@ -55,4 +55,8 @@
 # define __glibcxx_mutex_unlock(NAME) __gthread_mutex_unlock(&NAME)
 
+// Needed for __gnu_cxx::lock class
+# define __glibcxx_mutex(NAME) NAME, NAME ## _once, NAME ## _init
+# define __glibcxx_mutex_parms(NAME) __gthread_mutex_t& NAME, 
__gthread_once_t& NAME ## _once, void (* NAME ## _init) ()
+
 #else
 
@@ -63,4 +67,10 @@
 #endif
 
+// Needed for __gnu_cxx::lock class
+#ifndef __glibcxx_mutex
+# define __glibcxx_mutex(NAME) NAME
+# define __glibcxx_mutex_parms(NAME) __gthread_mutex_t& NAME
+#endif
+
 namespace __gnu_cxx
 {
@@ -68,14 +78,14 @@
   {
     // Externally defined and initialized.
-    __gthread_mutex_t* device;
+    __gthread_mutex_t& device;
 
   public:
     // Acquire the mutex here with a constructor call.  This ensures
     // that it is released in exit or during stack unwinding.
-    explicit lock(__gthread_mutex_t& name) : device(&name)
-    { __glibcxx_mutex_lock(*device); }
+    explicit lock( __glibcxx_mutex_parms(name) ) : device(name)
+    { __glibcxx_mutex_lock(name); }
 
     ~lock() throw()
-    { __glibcxx_mutex_unlock(*device); }
+    { __glibcxx_mutex_unlock(device); }
 
   private:
Index: src/locale_init.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/src/locale_init.cc,v
retrieving revision 1.14
diff -u -2 -r1.14 locale_init.cc
--- src/locale_init.cc	25 Jun 2004 06:10:44 -0000	1.14
+++ src/locale_init.cc	29 Jun 2004 20:26:59 -0000
@@ -102,5 +102,5 @@
   { 
     _S_initialize();
-    __gnu_cxx::lock sentry(__gnu_internal::locale_cons_mutex);
+    __gnu_cxx::lock sentry(__glibcxx_mutex(locale_cons_mutex));
     _S_global->_M_add_reference();
     _M_impl = _S_global;
@@ -113,5 +113,5 @@
     _Impl* __old;
     {
-      __gnu_cxx::lock sentry(__gnu_internal::locale_global_mutex);
+      __gnu_cxx::lock sentry(__glibcxx_mutex(locale_global_mutex));
       __old = _S_global;
       __other._M_impl->_M_add_reference();


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[per at bothner dot com]

------- Additional Comments From per at bothner dot com  2004-06-29 22:28 -------
Subject: Re:  [3.5 Regression] recent concurrence.h chanes
 breaks mingw bootstrap

membar at gcc dot gnu dot org wrote:

> ------- Additional Comments From membar at gcc dot gnu dot org  2004-06-29 20:34 -------
> AAARGH! You're right in your analyses for all the reasons you mentioned.
> 
> The "proper" solution would be to modify gthread_once, like you mentioned. But 
> that seems too far-reaching. As a compromise, why not answer a hack with a 
> hack?:

It's certainly a kludge.  My solution of doing the initialization
eagerly is cleaner, and makes lock marginally faster.  However,
start-up time is obviously very important, which argues for lazily
initializing the mutex using something like the "once" mechanism.

A clean and efficient solution is possible, but I don't think I
have time to pursue it.  I guess bkoz gets to pick a solution.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[membar at gcc dot gnu dot org]

------- Additional Comments From membar at gcc dot gnu dot org  2004-06-29 23:09 -------
Hi Per,

>A clean and efficient solution is possible, but I don't think I
>have time to pursue it.  I guess bkoz gets to pick a solution.

I agree that this is a kludge - the proper solution would be a
one-parameter init function, but like you said, this would be
more time-consuming.

After a current CVS get, pool_allocator.h is busted for the
same reasons. I'll submit a more formal patch if people agree
on my approach.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[membar at gcc dot gnu dot org]

------- Additional Comments From membar at gcc dot gnu dot org  2004-06-30 15:22 -------
Another iteration of the patch:

http://gcc.gnu.org/ml/libstdc++/2004-06/msg00384.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-06-30 21:06 -------


Aggh, yes, of course. I've changed it to a struct. I'm assuming that will work,
but I will wait for confirmation that this revised patch works before I check
this in.

-benjamin



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[per at bothner dot com]

------- Additional Comments From per at bothner dot com  2004-06-30 21:21 -------
Subject: Re:  [3.5 Regression] recent concurrence.h chanes
 breaks mingw bootstrap

bkoz at gcc dot gnu dot org wrote:

> ------- Additional Comments From bkoz at gcc dot gnu dot org  2004-06-30 21:06 -------
> 
> 
> Aggh, yes, of course. I've changed it to a struct. I'm assuming that will work,
> but I will wait for confirmation that this revised patch works before I check
> this in.

Nope:

/home/bothner/GNU/MinGW/build/crossgcc_build/gcc/xgcc -shared-libgcc 
-B/home/bothner/GNU/MinGW/build/crossgcc_build/gcc/ -nostdinc++ 
-L/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/src 
-L/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/src/.libs 
-B/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/bin/ 
-B/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/lib/ -isystem 
/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/include -isystem 
/home/bothner/GNU/MinGW/build/crossgcc/i686-pc-mingw32/sys-include 
-I/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/i686-pc-mingw32 
-I/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include 
-I/home/bothner/GNU/MinGW/gcc/libstdc++-v3/libsupc++ -O2 -g -g 
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual 
-fdiagnostics-show-location=once -c 
/home/bothner/GNU/MinGW/gcc/libstdc++-v3/src/allocator-inst.cc -o 
allocator-inst.o
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h: 
In member function `_Tp* __gnu_cxx::__pool_alloc<_Tp>::allocate(size_t, 
const void*) [with _Tp = char]':
/home/bothner/GNU/MinGW/gcc/libstdc++-v3/src/allocator-inst.cc:49: 
instantiated from here
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h:213: 
error: no matching function for call to 
`__gnu_cxx::lock::lock(__gthread_mutex_t&)'
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:89: 
note: candidates are: __gnu_cxx::lock::lock(const __gnu_cxx::lock&)
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:82: 
note:                 __gnu_cxx::lock::lock(__gnu_cxx::mutex_type&)
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h: 
In member function `void __gnu_cxx::__pool_alloc<_Tp>::deallocate(_Tp*, 
size_t) [with _Tp = char]':
/home/bothner/GNU/MinGW/gcc/libstdc++-v3/src/allocator-inst.cc:49: 
instantiated from here
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h:246: 
error: no matching function for call to 
`__gnu_cxx::lock::lock(__gthread_mutex_t&)'
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:89: 
note: candidates are: __gnu_cxx::lock::lock(const __gnu_cxx::lock&)
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:82: 
note:                 __gnu_cxx::lock::lock(__gnu_cxx::mutex_type&)
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h: 
In member function `_Tp* __gnu_cxx::__pool_alloc<_Tp>::allocate(size_t, 
const void*) [with _Tp = wchar_t]':
/home/bothner/GNU/MinGW/gcc/libstdc++-v3/src/allocator-inst.cc:50: 
instantiated from here
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h:213: 
error: no matching function for call to 
`__gnu_cxx::lock::lock(__gthread_mutex_t&)'
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:89: 
note: candidates are: __gnu_cxx::lock::lock(const __gnu_cxx::lock&)
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:82: 
note:                 __gnu_cxx::lock::lock(__gnu_cxx::mutex_type&)
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h: 
In member function `void __gnu_cxx::__pool_alloc<_Tp>::deallocate(_Tp*, 
size_t) [with _Tp = wchar_t]':
/home/bothner/GNU/MinGW/gcc/libstdc++-v3/src/allocator-inst.cc:50: 
instantiated from here
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/ext/pool_allocator.h:246: 
error: no matching function for call to 
`__gnu_cxx::lock::lock(__gthread_mutex_t&)'
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:89: 
note: candidates are: __gnu_cxx::lock::lock(const __gnu_cxx::lock&)
/home/bothner/GNU/MinGW/build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/include/bits/concurrence.h:82: 
note:                 __gnu_cxx::lock::lock(__gnu_cxx::mutex_type&)
make[3]: *** [allocator-inst.lo] Error 1
make[3]: Leaving directory 
`/misc/GNU/MinGC.build/crossgcc_build/i686-pc-mingw32/libstdc++-v3/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory 
`/misc/GNU/MinGC.build/crossgcc_build/i686-pc-mingw32/libstdc++-v3'
make[1]: *** [all] Error 2
make[1]: Leaving directory 
`/misc/GNU/MinGC.build/crossgcc_build/i686-pc-mingw32/libstdc++-v3'



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-06-30 21:44 -------

I've got a hacked gthr-default.h that replicates this under linux, where I can
actually deal with this. Hang on while I get this working on my end, then I'll
upload a new version of this.

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[aaronavay62 at aaronwl dot com]

------- Additional Comments From aaronavay62 at aaronwl dot com  2004-07-01 03:07 -------
> This compiles for me, both thread versions. Sorry about the previous rush.

I tried this patch out tonight on head on a i686-pc-mingw bootstrap, and it 
did not work:

/aaronwl/cs/compilers/gcc/build/mingw-head/gcc/xgcc -shared-libgcc -
B/aaronwl/cs/compilers/gcc/build/mingw-head/gcc/ -nostdinc++ -
L/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-v3/src -
L/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/src/.libs -B/aaronwl/cs/env/mingw-head-head-head/i686-pc-mingw32/bin/ -
B/aaronwl/cs/env/mingw-head-head-head/i686-pc-mingw32/lib/ -
isystem /aaronwl/cs/env/mingw-head-head-head/i686-pc-mingw32/include -
isystem /aaronwl/cs/env/mingw-head-head-head/i686-pc-mingw32/sys-include -
I/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/include/i686-pc-mingw32 -I/aaronwl/cs/compilers/gcc/build/mingw-head/i686-
pc-mingw32/libstdc++-v3/include -
I/aaronwl/cs/compilers/gcc/src/cvs/head/gcc/libstdc++-v3/libsupc++ -O2 -g -O2 -
g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -
Werror -fdiagnostics-show-location=once -
c ../../../../../src/cvs/head/gcc/libstdc++-v3/src/allocator.cc -o allocator.o
In file included from /aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-
mingw32/libstdc++-v3/include/ext/pool_allocator.h:54,
                 from ../../../../../src/cvs/head/gcc/libstdc++-
v3/src/allocator.cc:37:
/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/include/bits/concurrence.h: In constructor `__gnu_cxx::lock::lock
(__gthread_mutex_t&)':
/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/include/bits/concurrence.h:76: error: `device_once' was not declared in 
this scope
/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/include/bits/concurrence.h:76: error: `device_init' was not declared in 
this scope
/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/include/bits/concurrence.h:76: warning: unused variable 'device_once'
/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/include/bits/concurrence.h:76: warning: unused variable 'device_init'
../../../../../src/cvs/head/gcc/libstdc++-v3/src/allocator.cc: At global scope:
../../../../../src/cvs/head/gcc/libstdc++-v3/src/allocator.cc:54: error: 
expected constructor, destructor, or type conversion before '&' token
../../../../../src/cvs/head/gcc/libstdc++-v3/src/allocator.cc:54: error: 
expected `,' or `;' before '&' token

Sorry I don't have time to analyze it in detail right now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-07-01 04:13 -------
Hmmm. Are you sure you are using the p.20040630-4.2 patch? It does not have init
or once bits, so your error doesn't make sense to me.

Also:
/aaronwl/cs/compilers/gcc/build/mingw-head/i686-pc-mingw32/libstdc++-
v3/include/bits/concurrence.h: In constructor `__gnu_cxx::lock::lock
(__gthread_mutex_t&)':

should be

In constructor `__gnu_cxx::lock::lock(__glibcxx_mutex&)':

-benjamin

Are you sure you are using head sources with just the p.20040630-4.2 patch?

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[dannysmith at users dot sourceforge dot net]

------- Additional Comments From dannysmith at users dot sourceforge dot net  2004-07-01 05:50 -------
The revised patch (p.20040630-4.2) works for me on i686-pc-mingw32.  Thank you, 
Benjamin

(Aaron, I think you forgot to clean your build libstdc++ directory before 
testing the patch.)  

Danny

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-07-01 14:46 -------

Great, I'm going to check this in then. Thanks Danny.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-01 14:49 -------
Subject: Bug 16248

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	bkoz@gcc.gnu.org	2004-07-01 14:49:30

Modified files:
	libstdc++-v3   : ChangeLog 
	libstdc++-v3/include/bits: concurrence.h 
	libstdc++-v3/include/ext: pool_allocator.h 
	libstdc++-v3/src: allocator.cc 

Log message:
	2004-07-01  Benjamin Kosnik  <bkoz@redhat.com>
	Per Bothner  <per@bothner.com >
	Mohan Embar  <gnustuff@thisiscool.com>
	
	PR libstdc++/16248
	* include/bits/concurrence.h (__glibcxx_mutex_type): New.
	(__glibcxx_mutex): Encapsulate mutex init function into type for
	threaded configurations without __GTHREAD_MUTEX_INIT.
	(lock::lock): Make device member a reference.
	(lock::~lock): Same.
	* include/ext/pool_allocator.h (__pool_base::_M_get_mutex): Change
	to mutex_type.
	* src/allocator.cc: Same.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2555&r2=1.2556
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/concurrence.h.diff?cvsroot=gcc&r1=1.5&r2=1.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/pool_allocator.h.diff?cvsroot=gcc&r1=1.14&r2=1.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/allocator.cc.diff?cvsroot=gcc&r1=1.8&r2=1.9



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-01 15:30 -------
Subject: Bug 16248

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	bkoz@gcc.gnu.org	2004-07-01 15:30:39

Modified files:
	libstdc++-v3   : ChangeLog 

Log message:
	2004-07-01  Benjamin Kosnik  <bkoz@redhat.com>
	Per Bothner  <per@bothner.com>
	Mohan Embar  <gnustuff@thisiscool.com>
	
	PR libstdc++/16248
	* include/bits/concurrence.h (__glibcxx_mutex_type): New.
	(__glibcxx_mutex): Encapsulate mutex init function into type for
	threaded configurations without __GTHREAD_MUTEX_INIT.
	(lock::lock): Make device member a reference.
	(lock::~lock): Same.
	* include/ext/pool_allocator.h (__pool_base::_M_get_mutex): Change
	to mutex_type.
	* src/allocator.cc: Same.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2556&r2=1.2557



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-01 18:12 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[aaronavay62 at aaronwl dot com]

------- Additional Comments From aaronavay62 at aaronwl dot com  2004-07-01 22:36 -------
Sorry, yes, error between keyboard and chair.

Is there some way to get the build system to rebuild files in the libstdc++-v3 
build directory when dependents change in the source tree?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248

[Bug libstdc++/16248] [3.5 Regression] recent concurrence.h chanes breaks mingw bootstrap

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-07-13 01:21 -------
Subject: Bug 16248

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	bkoz@gcc.gnu.org	2004-07-13 01:21:48

Modified files:
	libstdc++-v3   : ChangeLog 
	libstdc++-v3/config: linker-map.gnu 
	libstdc++-v3/include/bits: concurrence.h 
	libstdc++-v3/include/ext: mt_allocator.h pool_allocator.h 
	libstdc++-v3/src: allocator-inst.cc allocator.cc 

Log message:
	2004-07-12  Benjamin Kosnik  <bkoz@redhat.com>
	
	* include/bits/concurrence.h: Tweak comments.
	
	2004-07-12  Benjamin Kosnik  <bkoz@redhat.com>
	Per Bothner  <per@bothner.com>
	Mohan Embar  <gnustuff@thisiscool.com>
	
	PR libstdc++/16248
	* include/bits/concurrence.h (__glibcxx_mutex_type): New.
	(__glibcxx_mutex): Encapsulate mutex init function into type for
	threaded configurations without __GTHREAD_MUTEX_INIT.
	(lock::lock): Make device member a reference.
	(lock::~lock): Same.
	* include/ext/pool_allocator.h (__pool_base::_M_get_mutex): Change
	to mutex_type.
	* src/allocator.cc: Same.
	
	2004-07-12  Brad Spencer  <spencer@infointeractive.com>
	
	* include/ext/mt_allocator.h: Handle allocations at static
	initialization that happen before _S_options is (automatically)
	constructed; set _S_init even if _M_force_new is true.
	
	2004-07-12  Paul Brook  <paul@codesourcery.com>
	
	* include/bits/concurrence.h: Still create mutex object when
	single-threaded.
	
	2004-07-12  Benjamin Kosnik  <bkoz@redhat.com>
	
	* include/bits/concurrence.h (__gnu_cxx::lock): New.
	* include/ext/pool_allocator.h (__pool_base::_Lock::_S_lock): Remove.
	(__pool_base::_M_get_mutex): New.
	* include/bits/allocator.h: Tweak.
	* src/allocator.cc (__pool_base::_M_get_free_list): Correct offset.
	
	* src/allocator.cc: Move all instantiations...
	* src/allocator-inst.cc: ...here.
	
	2004-07-12  Benjamin Kosnik  <bkoz@redhat.com>
	
	* include/ext/pool_allocator.h: Qualify __throw_bad_alloc.
	(__pool_base): Remove unused template parameter.  Add
	protected. Move lock data into __pool_base::_Lock. Remove static
	on member functions.
	(__pool_base::_M_get_free_list): New.
	(__pool_alloc): Move _S_force new here.
	* src/allocator.cc: Move out of line __pool_base definitions here.
	* config/linker-map.gnu: Export bits from __pool_base.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2224.2.140&r2=1.2224.2.141
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/linker-map.gnu.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.52.4.8&r2=1.52.4.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/concurrence.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1.8.1&r2=1.1.8.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/mt_allocator.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.8.2.5&r2=1.8.2.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/ext/pool_allocator.h.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.7.4.4&r2=1.7.4.5
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/allocator-inst.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.2.20.1&r2=1.2.20.2
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/allocator.cc.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.4.4.3&r2=1.4.4.4



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16248