PATCH (as applied to mainline): Fix a multiprocessor sparc bug (more rarely, might also affect single-processor, multithreaded code)

[Loren James Rittle]

> Fixes test case found in libstdc++/5037 which was the first report
> with a reproducible test case of a long-standing rumored bug with the
> sparc port.  [Original patch removed.]

Static libraries built and checked fine with the original patch (only
the static libraries fully work in my sparc environment); but I
discovered that this explicit template instantiation is also required
whenever one tries to build the trivial C++ program which includes no
C++ headers but which is linked against shared libstdc++-v3.

Rebuilt libstdc++-v3 from scratch on sparc-sun-solaris2.7 and checked
with no regressions.  Applied to mainline.  Sorry this wasn't caught
before the original patch was approved and committed.

Note: As exposed to the C++ compiler, we only ever take the pointer of
this symbol (inline asm instructions actually use the pointer in a
manner not directly seen by the compiler).  I assume this is why the
compiler is not implicitly instantiating the template in this case
since Solaris otherwise has good support in this area.  Either that or
I am confused about when an explicit template instantiation is required.

        * config/cpu/sparc/sparc32/bits/atomicity.h
        (__Atomicity_lock<0>::_S_atomicity_lock): Add.

Index: config/cpu/sparc/sparc32/bits/atomicity.h
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/config/cpu/sparc/sparc32/bits/atomicity.h,v
retrieving revision 1.5
diff -c -r1.5 atomicity.h
*** atomicity.h	2001/12/08 00:59:11	1.5
--- atomicity.h	2001/12/11 09:19:07
***************
*** 41,46 ****
--- 41,48 ----
  template <int __inst>
  unsigned char __Atomicity_lock<__inst>::_S_atomicity_lock = 0;
  
+ template unsigned char __Atomicity_lock<0>::_S_atomicity_lock;
+ 
  static int
  __attribute__ ((__unused__))
  __exchange_and_add (volatile _Atomic_word* __mem, int __val)