(1.0.2) std/bastring.h change -- Why add std/bastring.cc?

(1.0.2) std/bastring.h change -- Why add std/bastring.cc?

[Mumit Khan]

Both pre-1.0.2 and new'ish snapshots have the Jason's Feb 12 change
where he adds bastring.cc to bastring.h. Why was this necessary? It
would seem to cause unnecessary code-bloat on non-ELF (and PE when 
the bugs are fixed) systems. What am I missing here?

For example, given the following code on sparc-sun-sunos4.1.3, stock 
assembler: 

  #include <string>
  int main () {
      string s ("hello");
      return 0;
  }

before:

  U   basic_string<char, string_char_traits<char> >::~basic_string(void)
  U   basic_string<char, string_char_traits<char> >::basic_string(char const *)

and now (Yikes!):
  
  t   __default_alloc_template<false, 0>::FREELIST_INDEX(unsigned int)
  t   __default_alloc_template<false, 0>::ROUND_UP(unsigned int)
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::~basic_string(void)
  t   ___dl__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03RepPv
  t   ___nw__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03RepUiUi
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::basic_string(char const *)
  U   basic_string<char, string_char_traits<char>,
	__default_alloc_template<false, 0> >::nilRep
  t   __malloc_alloc_template<0>::allocate(unsigned int)
  t   __default_alloc_template<false, 0>::allocate(unsigned int)
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::assign(char const *)
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::assign(char const *, unsigned int)
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::capacity(void) const
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::check_realloc(unsigned int) const
  t   __default_alloc_template<false, 0>::chunk_alloc(unsigned int, int &)
  t   _clone__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03Rep
  t   _copy__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03RepUiPCcUi
  t   _create__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03RepUi
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::data(void) const
  t   _data__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03Rep
  t   __default_alloc_template<false, 0>::deallocate(void *, unsigned int)
  t   _excess_slop__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03RepUiUi
  t   _frob_size__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03RepUi
  t   _grab__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03Rep
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::length(void) const
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::max_size(void) const
  t   _move__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03RepUiPCcUi
  t   __default_alloc_template<false, 0>::refill(unsigned int)
  t   _release__Q2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03Rep
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::rep(void) const
  t   basic_string<char, string_char_traits<char>, 
	__default_alloc_template<false, 0> >::replace(unsigned int, unsigned int, char const *, unsigned int)
  t   _repup__t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i0PQ2t12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_template2b0i03Rep

Regards,
Mumit

Re: (1.0.2) std/bastring.h change -- Why add std/bastring.cc?

[Joe Buck]

> Both pre-1.0.2 and new'ish snapshots have the Jason's Feb 12 change
> where he adds bastring.cc to bastring.h. Why was this necessary? It
> would seem to cause unnecessary code-bloat on non-ELF (and PE when 
> the bugs are fixed) systems. What am I missing here?

It is bloat on ELF platforms too: bigger object files, and the string
functions are no longer in the shared library.

Re: (1.0.2) std/bastring.h change -- Why add std/bastring.cc?

[Jason Merrill]

>>>>> Joe Buck <jbuck@synopsys.com> writes:

>> Both pre-1.0.2 and new'ish snapshots have the Jason's Feb 12 change
>> where he adds bastring.cc to bastring.h. Why was this necessary? It
>> would seem to cause unnecessary code-bloat on non-ELF (and PE when 
>> the bugs are fixed) systems. What am I missing here?

This was motivated by the undefined symbols on linux problem; the library
was being built thread-safe, and user code not, and the two are not
link-compatible.

In general, the previous arrangement was restricting people from using any
instantiation of basic_string other than the usual one.

> It is bloat on ELF platforms too: bigger object files, and the string
> functions are no longer in the shared library.

Actually, they are.

I suppose we should resurrect sinst.h.

Jason

Re: (1.0.2) std/bastring.h change -- Why add std/bastring.cc?

[H.J. Lu]

> 
> >>>>> Joe Buck <jbuck@synopsys.com> writes:
> 
> >> Both pre-1.0.2 and new'ish snapshots have the Jason's Feb 12 change
> >> where he adds bastring.cc to bastring.h. Why was this necessary? It
> >> would seem to cause unnecessary code-bloat on non-ELF (and PE when 
> >> the bugs are fixed) systems. What am I missing here?
> 
> This was motivated by the undefined symbols on linux problem; the library
> was being built thread-safe, and user code not, and the two are not
> link-compatible.
> 
> In general, the previous arrangement was restricting people from using any
> instantiation of basic_string other than the usual one.
> 

Well, my STL addresses exactly that problem in a different approach.
It builds libstdc++ thread-safe, but uses the weak symbols in glibc
to deal with non-thread user code. BTW, it is the way how we make
glibc thread-safe.


H.J.

Re: (1.0.2) std/bastring.h change -- Why add std/bastring.cc?

[Mumit Khan]

Jason Merrill <jason@cygnus.com> writes:
> 
> I suppose we should resurrect sinst.h.
> 

Please do. I'd rather not see 1.0.2 released with the current scheme.
I just built a moderately large project hat went up 20% in disk usage 
and also about ~15% in link time on ELF, and on sparc-sunso4.1.3, the 
results were much worse both in time and space.

Regards,
Mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

Re: (1.0.2) std/bastring.h change -- Why add std/bastring.cc?

[H.J. Lu]

> 
> Jason Merrill <jason@cygnus.com> writes:
> > 
> > I suppose we should resurrect sinst.h.
> > 
> 
> Please do. I'd rather not see 1.0.2 released with the current scheme.
> I just built a moderately large project hat went up 20% in disk usage 
> and also about ~15% in link time on ELF, and on sparc-sunso4.1.3, the 
> results were much worse both in time and space.
> 

Here is the patch. I have another patch for STL to deal with
thread-safe on glibc 2.


-- 
H.J. Lu (hjl@gnu.org)
----
Wed Feb 18 07:33:14 1998  H.J. Lu  (hjl@gnu.org)

	* std/bastring.h: Don't include <std/bastring.cc>.

	* std/bastring.cc: Include <cstddef> and <std/bastring.h>.

	* sinst.cc: Just include <std/bastring.cc>.

--- ../../../import/egcs/libstdc++/std/bastring.h	Tue Feb 10 08:07:33 1998
+++ std/bastring.h	Wed Feb 18 12:29:55 1998
@@ -607,6 +607,4 @@
 
 } // extern "C++"
 
-#include <std/bastring.cc>
-
 #endif
--- ../../../import/egcs/libstdc++/std/bastring.cc	Tue Feb 10 08:07:32 1998
+++ std/bastring.cc	Wed Feb 18 12:29:55 1998
@@ -25,6 +25,9 @@
 // Written by Jason Merrill based upon the specification by Takanori Adachi
 // in ANSI X3J16/94-0013R2.
 
+#include <cstddef>
+#include <std/bastring.h>
+
 extern "C++" {
 template <class charT, class traits, class Allocator>
 inline void * basic_string <charT, traits, Allocator>::Rep::
--- ../../../import/egcs/libstdc++/sinst.cc	Tue Feb 10 08:07:30 1998
+++ sinst.cc	Wed Feb 18 12:29:55 1998
@@ -33,7 +33,7 @@
 #endif
 #endif
 
-#include <string>
+#include <std/bastring.cc>
 
 #ifdef C
 typedef char c;

A STL patch for egcs 1.0.2

[H.J. Lu]

> 
> Jason Merrill <jason@cygnus.com> writes:
> > 
> > I suppose we should resurrect sinst.h.
> > 
> 
> Please do. I'd rather not see 1.0.2 released with the current scheme.
> I just built a moderately large project hat went up 20% in disk usage 
> and also about ~15% in link time on ELF, and on sparc-sunso4.1.3, the 
> results were much worse both in time and space.
> 

Ulrich, this will make STL thread-safe for glibc 2 and at the same
time, the non-thread code should be ok. Can you take a look? libstdc++
in egcs 1.0.2 should be fixed for glibc 2.

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
---
Wed Jan 14 16:15:05 1998  H.J. Lu  (hjl@gnu.org)

	* ropeimpl.h: Include <stl_config.h>.
	* stl_alloc.h: Ditto.
	* stl_rope.h: Ditto.

	* ropeimpl.h (__STL_PTHREADS_ENABLED): Check
	__STL_PTHREADS_ENABLED instead of _PTHREADS.
	* stl_alloc.h: Ditto.
	* stl_config.h: Ditto.
	* stl_rope.h: Ditto.

	* stl_config.h: include <_G_config.h> if __GNUG__ is defined.
	(__STL_PTHREADS_ENABLED): Defined if _PTHREADS is defined or
	__GLIBC__ >= 2.

Index: ropeimpl.h
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libstdc++/stl/ropeimpl.h,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 ropeimpl.h
--- ropeimpl.h	1997/11/06 16:57:29	1.1.1.3
+++ ropeimpl.h	1998/01/14 23:59:43
@@ -17,6 +17,7 @@
 
 # include <stdio.h>
 # include <iostream.h>
+# include <stl_config.h>
 
 __STL_BEGIN_NAMESPACE
 
@@ -1429,7 +1430,7 @@
 
 template<class charT, class Alloc> charT rope<charT,Alloc>::empty_c_str[1];
 
-# ifdef _PTHREADS
+# ifdef __STL_PTHREADS_ENABLED
     template<class charT, class Alloc>
     pthread_mutex_t rope<charT,Alloc>::swap_lock = PTHREAD_MUTEX_INITIALIZER;
 # endif
Index: stl_alloc.h
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libstdc++/stl/stl_alloc.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 stl_alloc.h
--- stl_alloc.h	1997/11/06 16:57:30	1.1.1.1
+++ stl_alloc.h	1998/01/15 00:00:08
@@ -57,16 +57,17 @@
 #include <stdlib.h>
 #include <string.h>
 #include <assert.h>
+#include <stl_config.h>
 #ifndef __RESTRICT
 #  define __RESTRICT
 #endif
 
-#if !defined(_PTHREADS) && !defined(_NOTHREADS) \
+#if !defined(__STL_PTHREADS_ENABLED) && !defined(_NOTHREADS) \
  && !defined(__STL_SGI_THREADS) && !defined(__STL_WIN32THREADS)
 #   define _NOTHREADS
 #endif
 
-# ifdef _PTHREADS
+# ifdef __STL_PTHREADS_ENABLED
     // POSIX Threads
     // This is dubious, since this is likely to be a high contention
     // lock.   Performance may not be adequate.
@@ -357,7 +358,7 @@
     static inline void __unlock(volatile unsigned long *);
 # endif
 
-# ifdef _PTHREADS
+# ifdef __STL_PTHREADS_ENABLED
     static pthread_mutex_t __node_allocator_lock;
 # endif
 
@@ -558,7 +559,7 @@
     return(result);
 }
 
-#ifdef _PTHREADS
+#ifdef __STL_PTHREADS_ENABLED
     template <bool threads, int inst>
     pthread_mutex_t
     __default_alloc_template<threads, inst>::__node_allocator_lock
Index: stl_config.h
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libstdc++/stl/stl_config.h,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 stl_config.h
--- stl_config.h	1997/11/06 16:57:28	1.1.1.3
+++ stl_config.h	1998/01/15 00:00:38
@@ -71,6 +71,15 @@
 //  (19) Defines __stl_assert either as a test or as a null macro,
 //       depending on whether or not __STL_ASSERTIONS is defined.
 
+#ifdef __GNUG__
+#include <_G_config.h>
+#endif
+
+#if !defined(__STL_PTHREADS_ENABLED) && (defined(_PTHREADS) \
+ || (defined(__GLIBC__) && __GLIBC__ >= 2))
+#   define __STL_PTHREADS_ENABLED
+#endif
+
 # if defined(__sgi) && !defined(__GNUC__)
 #   if !defined(_BOOL)
 #     define __STL_NEED_BOOL
@@ -93,7 +102,7 @@
 #   if (_COMPILER_VERSION >= 721) && defined(_NAMESPACES)
 #     define __STL_USE_NAMESPACES
 #   endif 
-#   if !defined(_NOTHREADS) && !defined(_PTHREADS)
+#   if !defined(_NOTHREADS) && !defined(__STL_PTHREADS_ENABLED)
 #     define __STL_SGI_THREADS
 #   endif
 # endif
Index: stl_rope.h
===================================================================
RCS file: /home/work/cvs/gnu/egcs/libstdc++/stl/stl_rope.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 stl_rope.h
--- stl_rope.h	1997/11/06 16:57:31	1.1.1.1
+++ stl_rope.h	1998/01/15 00:01:48
@@ -18,6 +18,8 @@
 #ifndef __SGI_STL_INTERNAL_ROPE_H
 # define __SGI_STL_INTERNAL_ROPE_H
 
+# include <stl_config.h>
+
 # ifdef __GC
 #   define __GC_CONST const
 # else
@@ -306,7 +308,7 @@
             {
                 return InterlockedDecrement(&refcount);
             }
-#	elif defined(_PTHREADS)
+#	elif defined(__STL_PTHREADS_ENABLED)
 	    // This should be portable, but performance is expected
 	    // to be quite awful.  This really needs platform specific
 	    // code.
@@ -939,7 +941,7 @@
 	    static cstrptr atomic_swap(cstrptr *p, cstrptr q) {
 		return (cstrptr) InterlockedExchange((LPLONG)p, (LONG)q);
 	    }
-#	elif defined(_PTHREADS)
+#	elif defined(__STL_PTHREADS_ENABLED)
 	    // This should be portable, but performance is expected
 	    // to be quite awful.  This really needs platform specific
 	    // code.

Re: (1.0.2) std/bastring.h change -- Why add std/bastring.cc?

[Jason Merrill]

I've reverted my change for 1.0.2.

Jason

Re: A STL patch for egcs 1.0.2

[H.J. Lu]

> 
> >>>>> H J Lu <hjl@lucon.org> writes:
> 
> > Ulrich, this will make STL thread-safe for glibc 2 and at the same
> > time, the non-thread code should be ok. Can you take a look? libstdc++
> > in egcs 1.0.2 should be fixed for glibc 2.
> 
> I still think not enough people are writing threaded code to make this

It is kind of saying noone uses namespace with g++. Yes, they are
people using thread with glibc 2. Yes, some of them use C++. I don't
think making libstdc++ thread-unsafe is acceptable for glibc 2. BTW,
my change only affects glibc 2. The rest remains the same.

> necessary for 1.0.2.  Also, your patch changes more than necessary; there's
> no need to add #includes of stl_config.h.
> 

STL needs a way to find the system is based on glibc 2 so that
thread is enabled for glibc 2 automatically. Do you have any
suggestions?


-- 
H.J. Lu (hjl@gnu.org)

Re: A STL patch for egcs 1.0.2

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

> Ulrich, this will make STL thread-safe for glibc 2 and at the same
> time, the non-thread code should be ok. Can you take a look? libstdc++
> in egcs 1.0.2 should be fixed for glibc 2.

I still think not enough people are writing threaded code to make this
necessary for 1.0.2.  Also, your patch changes more than necessary; there's
no need to add #includes of stl_config.h.

Jason

Re: A STL patch for egcs 1.0.2

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

>> I still think not enough people are writing threaded code to make this

> It is kind of saying noone uses namespace with g++. Yes, they are
> people using thread with glibc 2. Yes, some of them use C++. I don't
> think making libstdc++ thread-unsafe is acceptable for glibc 2. BTW,
> my change only affects glibc 2. The rest remains the same.

Oh, all right.

>> necessary for 1.0.2.  Also, your patch changes more than necessary; there's
>> no need to add #includes of stl_config.h.

> STL needs a way to find the system is based on glibc 2 so that
> thread is enabled for glibc 2 automatically. Do you have any
> suggestions?

I meant that stl_config.h will have been included already at the points
where you added the #includes, so they are no-ops.  Here's a simplified
patch, with a couple other changes that I suggested in our conversation
with Matt:

Wed Jan 14 16:15:05 1998  H.J. Lu  (hjl@gnu.org)

	* ropeimpl.h: Check __STL_PTHREADS instead of _PTHREADS.
	* stl_alloc.h: Ditto.
	* stl_config.h: Ditto.
	* stl_rope.h: Ditto.

	* stl_config.h: include <_G_config.h> if __GNUC__ is defined.
	(__STL_PTHREADS): Defined if _PTHREADS is defined or
	__GLIBC__ >= 2 and _NOTHREADS is not defined.

Index: ropeimpl.h
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/libstdc++/stl/ropeimpl.h,v
retrieving revision 1.2.2.1
diff -c -p -r1.2.2.1 ropeimpl.h
*** ropeimpl.h	1997/11/04 20:13:53	1.2.2.1
--- ropeimpl.h	1998/02/18 18:29:00
*************** rope<charT, Alloc>::rope(size_t n, charT
*** 1429,1435 ****
  
  template<class charT, class Alloc> charT rope<charT,Alloc>::empty_c_str[1];
  
! # ifdef _PTHREADS
      template<class charT, class Alloc>
      pthread_mutex_t rope<charT,Alloc>::swap_lock = PTHREAD_MUTEX_INITIALIZER;
  # endif
--- 1429,1435 ----
  
  template<class charT, class Alloc> charT rope<charT,Alloc>::empty_c_str[1];
  
! # ifdef __STL_PTHREADS
      template<class charT, class Alloc>
      pthread_mutex_t rope<charT,Alloc>::swap_lock = PTHREAD_MUTEX_INITIALIZER;
  # endif
Index: stl_alloc.h
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/libstdc++/stl/stl_alloc.h,v
retrieving revision 1.1.2.1
diff -c -p -r1.1.2.1 stl_alloc.h
*** stl_alloc.h	1997/11/04 20:14:06	1.1.2.1
--- stl_alloc.h	1998/02/18 18:29:01
***************
*** 61,72 ****
  #  define __RESTRICT
  #endif
  
! #if !defined(_PTHREADS) && !defined(_NOTHREADS) \
   && !defined(__STL_SGI_THREADS) && !defined(__STL_WIN32THREADS)
  #   define _NOTHREADS
  #endif
  
! # ifdef _PTHREADS
      // POSIX Threads
      // This is dubious, since this is likely to be a high contention
      // lock.   Performance may not be adequate.
--- 61,72 ----
  #  define __RESTRICT
  #endif
  
! #if !defined(__STL_PTHREADS) && !defined(_NOTHREADS) \
   && !defined(__STL_SGI_THREADS) && !defined(__STL_WIN32THREADS)
  #   define _NOTHREADS
  #endif
  
! # ifdef __STL_PTHREADS
      // POSIX Threads
      // This is dubious, since this is likely to be a high contention
      // lock.   Performance may not be adequate.
*************** private:
*** 357,363 ****
      static inline void __unlock(volatile unsigned long *);
  # endif
  
! # ifdef _PTHREADS
      static pthread_mutex_t __node_allocator_lock;
  # endif
  
--- 357,363 ----
      static inline void __unlock(volatile unsigned long *);
  # endif
  
! # ifdef __STL_PTHREADS
      static pthread_mutex_t __node_allocator_lock;
  # endif
  
*************** __default_alloc_template<threads, inst>:
*** 558,564 ****
      return(result);
  }
  
! #ifdef _PTHREADS
      template <bool threads, int inst>
      pthread_mutex_t
      __default_alloc_template<threads, inst>::__node_allocator_lock
--- 558,564 ----
      return(result);
  }
  
! #ifdef __STL_PTHREADS
      template <bool threads, int inst>
      pthread_mutex_t
      __default_alloc_template<threads, inst>::__node_allocator_lock
Index: stl_config.h
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/libstdc++/stl/stl_config.h,v
retrieving revision 1.3.2.1
diff -c -p -r1.3.2.1 stl_config.h
*** stl_config.h	1997/11/04 20:14:09	1.3.2.1
--- stl_config.h	1998/02/18 18:29:01
***************
*** 71,76 ****
--- 71,80 ----
  //  (19) Defines __stl_assert either as a test or as a null macro,
  //       depending on whether or not __STL_ASSERTIONS is defined.
  
+ #if defined(_PTHREADS)
+ #   define __STL_PTHREADS
+ #endif
+ 
  # if defined(__sgi) && !defined(__GNUC__)
  #   if !defined(_BOOL)
  #     define __STL_NEED_BOOL
***************
*** 93,105 ****
  #   if (_COMPILER_VERSION >= 721) && defined(_NAMESPACES)
  #     define __STL_USE_NAMESPACES
  #   endif 
! #   if !defined(_NOTHREADS) && !defined(_PTHREADS)
  #     define __STL_SGI_THREADS
  #   endif
  # endif
  
  # ifdef __GNUC__
! #   if 0 && (__GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 8))
  #     define __STL_STATIC_TEMPLATE_MEMBER_BUG
  #     define __STL_NEED_TYPENAME
  #     define __STL_NEED_EXPLICIT
--- 97,110 ----
  #   if (_COMPILER_VERSION >= 721) && defined(_NAMESPACES)
  #     define __STL_USE_NAMESPACES
  #   endif 
! #   if !defined(_NOTHREADS) && !defined(__STL_PTHREADS)
  #     define __STL_SGI_THREADS
  #   endif
  # endif
  
  # ifdef __GNUC__
! #   include <_G_config.h>
! #   if __GNUC__ < 2 || (__GNUC__ == 2 && __GNUC_MINOR__ < 8)
  #     define __STL_STATIC_TEMPLATE_MEMBER_BUG
  #     define __STL_NEED_TYPENAME
  #     define __STL_NEED_EXPLICIT
***************
*** 108,113 ****
--- 113,121 ----
  #     define __STL_FUNCTION_TMPL_PARTIAL_ORDER
  #     define __STL_EXPLICIT_FUNCTION_TMPL_ARGS
  #     define __STL_MEMBER_TEMPLATES
+ #   endif
+ #   if !defined(_NOTHREADS) && __GLIBC__ >= 2
+ #     define __STL_PTHREADS
  #   endif
  #   ifdef __EXCEPTIONS
  #     define __STL_USE_EXCEPTIONS
Index: stl_rope.h
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/libstdc++/stl/stl_rope.h,v
retrieving revision 1.1.2.1
diff -c -p -r1.1.2.1 stl_rope.h
*** stl_rope.h	1997/11/04 20:14:35	1.1.2.1
--- stl_rope.h	1998/02/18 18:29:01
*************** struct __rope_RopeBase {
*** 306,312 ****
              {
                  return InterlockedDecrement(&refcount);
              }
! #	elif defined(_PTHREADS)
  	    // This should be portable, but performance is expected
  	    // to be quite awful.  This really needs platform specific
  	    // code.
--- 306,312 ----
              {
                  return InterlockedDecrement(&refcount);
              }
! #	elif defined(__STL_PTHREADS)
  	    // This should be portable, but performance is expected
  	    // to be quite awful.  This really needs platform specific
  	    // code.
*************** class rope {
*** 939,945 ****
  	    static cstrptr atomic_swap(cstrptr *p, cstrptr q) {
  		return (cstrptr) InterlockedExchange((LPLONG)p, (LONG)q);
  	    }
! #	elif defined(_PTHREADS)
  	    // This should be portable, but performance is expected
  	    // to be quite awful.  This really needs platform specific
  	    // code.
--- 939,945 ----
  	    static cstrptr atomic_swap(cstrptr *p, cstrptr q) {
  		return (cstrptr) InterlockedExchange((LPLONG)p, (LONG)q);
  	    }
! #	elif defined(__STL_PTHREADS)
  	    // This should be portable, but performance is expected
  	    // to be quite awful.  This really needs platform specific
  	    // code.

Re: A STL patch for egcs 1.0.2

[Ulrich Drepper]

Jason Merrill <jason@cygnus.com> writes:

> I still think not enough people are writing threaded code to make this
> necessary for 1.0.2.

For glibc based systems where threading is working it is used a lot.
We get lots of mails about threading and C++.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: A STL patch for egcs 1.0.2

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

>> > The problem is how you can be sure stl_config.h will be always included
>> > in the user code since libstdc++ and the user code have to match?
>> 
>> Because it is.  Nobody will be including, say, ropeimpl.h directly, they'll
>> include <rope>, which gets stl_config.h before ropeimpl.h.  How else would

> How about stl_alloc.h and stl_rope.h?

If people include those directly, they deserve what they get.  To wit:

/* NOTE: This is an internal header file, included by other STL headers.
 *   You should not attempt to use it directly.
 */

>> the current thread #ifdefs work?

> It assumes -D_PTHREADS.

I meant the #ifdef __STL_SGI_THREADS.

> If those are not problem, can we put them in 1.0.2?

Done.

Jason

Re: A STL patch for egcs 1.0.2

[H.J. Lu]

> > The problem is how you can be sure stl_config.h will be always included
> > in the user code since libstdc++ and the user code have to match?
> 
> Because it is.  Nobody will be including, say, ropeimpl.h directly, they'll
> include <rope>, which gets stl_config.h before ropeimpl.h.  How else would

How about stl_alloc.h and stl_rope.h?

> the current thread #ifdefs work?

It assumes -D_PTHREADS.

> 
> > I am not use if _NOTHREADS will work since you have to define it
> > both when libstdc++ is built and is used by the user code. How do
> > you make sure that?
> 
> I don't.  Users can worry about it if they really want to.  Anyway, you
> don't have to define it the same both ways; that just means you get two
> copies of the STL code.
> 
> Jason
> 

If those are not problem, can we put them in 1.0.2?

Thanks.


-- 
H.J. Lu (hjl@gnu.org)

Re: A STL patch for egcs 1.0.2

[Jason Merrill]

>>>>> H J Lu <hjl@lucon.org> writes:

>> >> necessary for 1.0.2.  Also, your patch changes more than necessary; there's
>> >> no need to add #includes of stl_config.h.
>> 
>> > STL needs a way to find the system is based on glibc 2 so that
>> > thread is enabled for glibc 2 automatically. Do you have any
>> > suggestions?
>> 
>> I meant that stl_config.h will have been included already at the points

> The problem is how you can be sure stl_config.h will be always included
> in the user code since libstdc++ and the user code have to match?

Because it is.  Nobody will be including, say, ropeimpl.h directly, they'll
include <rope>, which gets stl_config.h before ropeimpl.h.  How else would
the current thread #ifdefs work?

> I am not use if _NOTHREADS will work since you have to define it
> both when libstdc++ is built and is used by the user code. How do
> you make sure that?

I don't.  Users can worry about it if they really want to.  Anyway, you
don't have to define it the same both ways; that just means you get two
copies of the STL code.

Jason

Re: A STL patch for egcs 1.0.2

[H.J. Lu]

> >> necessary for 1.0.2.  Also, your patch changes more than necessary; there's
> >> no need to add #includes of stl_config.h.
> 
> > STL needs a way to find the system is based on glibc 2 so that
> > thread is enabled for glibc 2 automatically. Do you have any
> > suggestions?
> 
> I meant that stl_config.h will have been included already at the points

The problem is how you can be sure stl_config.h will be always included
in the user code since libstdc++ and the user code have to match?

> where you added the #includes, so they are no-ops.  Here's a simplified
> patch, with a couple other changes that I suggested in our conversation
> with Matt:
> 
> Wed Jan 14 16:15:05 1998  H.J. Lu  (hjl@gnu.org)
> 
> 	* ropeimpl.h: Check __STL_PTHREADS instead of _PTHREADS.
> 	* stl_alloc.h: Ditto.
> 	* stl_config.h: Ditto.
> 	* stl_rope.h: Ditto.
> 
> 	* stl_config.h: include <_G_config.h> if __GNUC__ is defined.
> 	(__STL_PTHREADS): Defined if _PTHREADS is defined or
> 	__GLIBC__ >= 2 and _NOTHREADS is not defined.

I am not use if _NOTHREADS will work since you have to define it
both when libstdc++ is built and is used by the user code. How do
you make sure that?


H.J.

Re: A STL patch for egcs 1.0.2

[Jeffrey A Law]

  In message < r24t1vi6wr.fsf@happy.cygnus.com >you write:
  > Jason Merrill <jason@cygnus.com> writes:
  > 
  > > I still think not enough people are writing threaded code to make this
  > > necessary for 1.0.2.
  > 
  > For glibc based systems where threading is working it is used a lot.
  > We get lots of mails about threading and C++.
But that does necessarily not mean we need to deal with this for
1.0.2.

1.0.2 does not have to be perfect, it needs to address the most
serious problems with 1.0.1.  I think we've basically done that.

So, it seems to me we need to get 1.0.2 out the door, then start
working towards a 1.1 release.

jeff

Re: A STL patch for egcs 1.0.2

[Jeffrey A Law]

  In message < m0y71T7-00058gC@ocean.lucon.org >you write:
  > >   > For glibc based systems where threading is working it is used a lot.
  > >   > We get lots of mails about threading and C++.
  > > But that does necessarily not mean we need to deal with this for
  > > 1.0.2.
  > > 
  > > 1.0.2 does not have to be perfect, it needs to address the most
  > > serious problems with 1.0.1.  I think we've basically done that.
  > > 
  > 
  > Jason has installed the patch. It is necessary for people to
  > use thread in C++ with egcs 1.0.2.
I'm aware of Jason's checkin.

I was making a point about releases in general, not about your patch
specifically.

jeff

Re: A STL patch for egcs 1.0.2

[H.J. Lu]

> 
>   In message < r24t1vi6wr.fsf@happy.cygnus.com >you write:
>   > Jason Merrill <jason@cygnus.com> writes:
>   > 
>   > > I still think not enough people are writing threaded code to make this
>   > > necessary for 1.0.2.
>   > 
>   > For glibc based systems where threading is working it is used a lot.
>   > We get lots of mails about threading and C++.
> But that does necessarily not mean we need to deal with this for
> 1.0.2.
> 
> 1.0.2 does not have to be perfect, it needs to address the most
> serious problems with 1.0.1.  I think we've basically done that.
> 

Jason has installed the patch. It is necessary for people to
use thread in C++ with egcs 1.0.2.

-- 
H.J. Lu (hjl@gnu.org)