This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

g++ static data members [solaris27 + gcc-2.95.2/egcs]



I've noticed a problem with static data members of templates not
getting initialized correctly when I'm using a solaris host. The same
code, with the same compiler and linker work correctly under linux.

I believe this problem has to do with cc1plus not putting the data
into the correct section: here are two snippets from example code
included below. Both come from 'g++ -S sol27-data.cc':

What I get with gcc-2.95.2 (--with-gnu-as --with-gnu-ld) on solaris2.7:

        .global _t5ctype1Zc._S_table
.section        ".bss"
        .align 4
        .type    _t5ctype1Zc._S_table,#object
        .size    _t5ctype1Zc._S_table,4
_t5ctype1Zc._S_table:
        .skip 4


The equivalent output from x86-linux:

.data
	.align 4
	.type	 _t5ctype1Zc._S_table,@object
	.size	 _t5ctype1Zc._S_table,4
_t5ctype1Zc._S_table:
	.long __ctype_b


Under solaris, _S_table is initialized to zero, and under linux the
_S_table is correctly initialized with __ctype_b. _S_table in both
cases is a reference to data in the "C" library. (In the linux case,
__ctype_b comes from libc.) 

In libc.a under linux, 

Disassembly of section .data:

00000000 <__ctype_b>:
   0:	00 01             	add    %al,(%ecx)
	...
[snip]


In libc.a under solaris2.7

3b8:   Disassembly of section .data:

[snip]

00000028 <__ctype_mask>:
  28:   00 00 00 00     unimp  0



It's clear to me that _S_table should be in .data, not .bss. Any
thoughts?  I've been unable to compile CVS egcs/gcc on solaris2.7, so
anybody with a current g++ binary care to run the code below through
it, and see what section _S_table is in?

Is there a patch to put data like this into .data and not .bss on solaris2.7?

Thanks,
Benjamin






Here are the sources:

//----sol27.h
#include <ctype.h>
#include <stddef.h>

  struct ctype_base
  {
    // solaris27
//    typedef unsigned int 	mask;
    // linux
    typedef unsigned short 	mask;
    // Non-standard typedefs.
    typedef int* 		__to_type;

  };


  template<typename _CharT>
  class ctype   : public ctype_base
    { };

  template<>
  class ctype<char>  : public ctype_base
    {
      // Types:
      typedef char char_type;
    private:
      // Data Members:
      const mask* 		_M_table;
      bool 			_M_del;
      static const mask* const& _S_table;
      
    public:

      explicit 
      ctype(const mask* __table = 0, bool __del = false, 
	    size_t __refs = 0) throw()
      : _M_table(__table == 0 ? _S_table: __table), 
	_M_del(__table != 0 && __del) { }

    };
// -------end sol27.h

//--------sol27-data.cc
#include "sol27.h"


// solaris2.7
//  const ctype_base::mask* const& ctype<char>::_S_table = __ctype_mask;

// linux
  const ctype_base::mask* const& ctype<char>::_S_table = __ctype_b;
// --------end sol27-data.cc



An earlier version of this bug was reported here.
http://gcc.gnu.org/ml/gcc-bugs/2000-03/msg00060.html



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]