This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
V3 PATCH: Explicitly instantiate string::npos
- To: libstdc++ at sources dot redhat dot com, patches at gcc dot gnu dot org
- Subject: V3 PATCH: Explicitly instantiate string::npos
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Sat, 28 Oct 2000 14:28:57 -0700
- Organization: CodeSourcery, LLC
I'm gradually making progress with the IRIX port of V3, needed for GCC
3.0.
I ran into an infinite loop on initialization that turned out to be
caused by a semi-bug in the compiler and a semi-bug in V3. (Fixing
either one would actually cure this problem, but both should be
fixed.)
Consider this test program:
template <class T>
struct U {
static int j;
};
template <class T>
struct S {
static const int i = 7;
};
template <class T>
const int S<T>::i;
template <class T>
int U<T>::j = S<T>::i + 5;
template int U<double>::j;
int main () {
}
Compile with -fno-implicit-templates:
bash$ g++1.sh -fno-implicit-templates test.C
/tmp/ccP80kVh.o: In function `__static_initialization_and_destruction_0':
/tmp/ccP80kVh.o(.text+0x32): undefined reference to `S<double>::i'
collect2: ld returned 1 exit status
It's pretty silly that the compiler doesn't resolve S<double>::i to
its constant intiailizer value (7). It's not technically a bug, but
it is a quality-of-implementation issue.
In the V3 case, this resulted in basic_string::_S_Rep::_S_max_size
(whose initializer depends on basic_string::_S_Rep::npos) being
dynamically initialized when explicitly instantiated in
string-inst.cc. That's not just a performance issue -- it's also a
correctness issue.
During start-up, some piece of the locale library creates a string
`"C"' corresponding to the current locale. But, since _S_max_size
wasn't initialized yet, the string-creation stuff thought the
1-character string was too long, and threw an exception. But,
initializing the exception caused the creation of a new string
(explaining that the string was too long). This string was too long,
too, of course, and we never even get to main...
Here's the V3 fix.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com
2000-10-28 Mark Mitchell <mark@codesourcery.com>
* src/string-inst.cc (basic_string<C>::npos): Explicitly
instantiate it.
Index: src/string-inst.cc
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/src/string-inst.cc,v
retrieving revision 1.9
diff -c -p -r1.9 string-inst.cc
*** string-inst.cc 2000/08/23 04:38:42 1.9
--- string-inst.cc 2000/10/28 21:21:31
*************** namespace std
*** 48,53 ****
--- 48,54 ----
typedef basic_string<C> S;
template C S::_Rep::_S_terminal;
+ template const S::size_type S::npos;
template S::size_type S::_Rep::_S_max_size;
template S::size_type S::_S_empty_rep_storage[];
template S::_Rep* S::_Rep::_S_create(size_t, S::allocator_type const&);