This is the mail archive of the
mailing list for the libstdc++ project.
Re: V3 static data in classes vs AIX
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: V3 static data in classes vs AIX
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Thu, 07 Jun 2001 18:45:24 -0400
- cc: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>, Alexandre Oliva <aoliva at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, gdr at codesourcery dot com, libstdc++ at gcc dot gnu dot org
>>>>> Benjamin Kosnik writes:
Ben> include/bits/basic_string.tcc has:
Ben> template<typename _CharT, typename _Traits, typename _Alloc>
Ben> const typename basic_string<_CharT, _Traits, _Alloc>::size_type
Ben> basic_string<_CharT, _Traits, _Alloc>::
Ben> _Rep::_S_max_size = (((npos - sizeof(_Rep))/sizeof(_CharT)) - 1) / 4;
Ben> So it's defined, or should be. Maybe implicit instantiations of class
Ben> templates doesn't instantiate nested class static data on AIX?
I think this is another example of the COMDAT problem. G++
assumes that it can emit duplicate weak instantiations which will be
merged. If a target does not have WEAK symbols, G++ currently does not
emit anything and it needs to be instantiated explicitly.
This is why Mark is suggesting doing the same thing for static
class members. I think that AIX "runtime linking" re-writing of the TOC
will merge those references and do the right thing. I am dealing with too
many other fires to test this at the moment.
The question seems to be a choice of being completely consistent
(to the point of being painful for programmers) OR use COMMON symbols for
GNU/Linux/SVR4 compatibility as much as most platforms can implement. I
currently am leaning toward the latter.
I do not think that holding to the June 15 release date is
reasonable given the number of high priority bugs. We are not allowing
any time for a real freeze and candidate release for testing because of
the significant changes still being implemented to address the high