Workshop 6 Bug with STLport hash_map operator []

Question

Using hash_map<string, string>:operator[] in a debug build crashes; in release, it doesn't. This must be a compiler bug, yes? Here's how to reproduce it.
<PRE>
[valhalla:~/test] $ cat t.c
#include <string>
#include <hash_map>
using namespace std;
main()
hash_map<string, string> m;
m["stl"] = "port";
string s = m["stl"];
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -I/apps/stlport-4.5.3/stlport -L/apps/stlport-4.5.3/lib -R/apps/stlport-4.5.3/lib -lstlport_sunpro t.c
[valhalla:~/test] $ a.out
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -g -I/apps/stlport-4.5.3/stlport -L/apps/stlport-4.5.3/lib -R/apps/stlport-4.5.3/lib -lstlport_sunpro t.c
[valhalla:~/test] $ a.out
Bus Error (core dumped)
[valhalla:~/test] $ dbx -q a.out core
core file header read successfully
program terminated by signal BUS (invalid address alignment)
Current function is STL::_stl_delete
99 inline void STLPCALL __stl_delete(void* __p) { ::operator delete(__p); }
(dbx) where
[1] freeunlocked(0xffbee657, 0xff23a000, 0xffbee657, 0xff23a000, 0x237e8, 0xff1c291c), at 0xff1c2974
[2] free(0xffbee657, 0xffbee5d4, 0xffbee658, 0xffbee5e2, 0xffbee5e1, 0xff19bb88), at 0xff1c2924
[3] operator delete(0xffbee657, 0xffbee658, 0xffbee657, 0xff37e540, 0x13bb0, 0x1ee00), at 0xff3636f8
=>[4] STL::_stl_delete(__p = 0xffbee657), line 99 in "new"
[5] STL::_node_alloc<true,0>::deallocate(__p = 0xffbee657, __n = 4347225U), line 253 in "_alloc.h"
[6] STL::allocator<char>::deallocate(this = 0xffbee5b0, _p = 0xffbee657 "", __n = 4347225U), line 360 in "_alloc.h"
[7] STL::STLP_alloc_proxy<char*,char,_STL::allocator<char> >::deallocate(this = 0xffbee5b0, __p = 0xffbee657 "", __n = 4347225U), line 506 in "_alloc.h"
[8] STL::String_base<char,_STL::allocator<char> >::_M_deallocate_block(this = 0xffbee5a8), line 124 in "_string.h"
[9] STL::String_base<char,_STL::allocator<char> >::~_String_base(this = 0xffbee5a8), line 135 in "_string.h"
[10] STL::basicstring<char,_STL::char_traits<char>,_STL::allocator<char> >::~basic_string(this = 0xffbee5a8), line 302 in "_string.h"
[11] STL::hashmap<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::hash<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >,_STL::equal_to<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >,_STL::allocator<_STL::pair<const STL::basicstring<char,_STL::char_traits<char>,_STL::allocator<char> >,_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > > > >::operator[](this = 0xffbee680, __key = CLASS), line 186 in "_hash_map.h"
[12] main(), line 8 in "t.c"
(dbx) exit
[valhalla:~/test] $ exit
exit
[valhalla:~/test] $ which CC
/apps/SUNWspro64/bin/CC
[valhalla:~/test] $ CC -V
CC: Sun WorkShop 6 update 1 C++ 5.2 Patch 109508-09 2002/07/08
[valhalla:~/test] $ uname -a
SunOS valhalla 5.8 Generic_108528-15 sun4u sparc SUNW,Sun-Blade-100
</PRE>
STLport places all of its classes in its own _STL namespace, so there is no concern for name collision with std types that come with the Sun compiler. 
Any ideas?
Regards,
Jason

Answer 1

I found out this is compiler bug with Forte 6 that ocurrs when inlining is enabled and temporaries are used in conditional expressions with the ?: operator, e.g.,
[valhalla:~/test] $ cat tt.c
#include <iostream>
#include <stdlib.h>
using namespace std;
struct X {
X() { cout << "X ctor" << endl; }
~X() { cout << "X dtor" << endl; }
int foo() { return 1; }
struct Y {
Y() { cout << "Y ctor" << endl; }
~Y() { cout << "Y dtor" << endl; }
int foo() { return 1; }
inline int foo(int i)
return i ?
X().foo() :
Y().foo() ;
main(int, char **argv)
return foo(atoi(argv[1]));
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC -g tt.c
[valhalla:~/test] $ a.out 1
X ctor
X dtor
[valhalla:~/test] $ rm -rf SunWS_cache/
[valhalla:~/test] $ CC tt.c
[valhalla:~/test] $ a.out 1
X ctor
Y dtor
X dtor
[valhalla:~/test] $ g++ tt.c
[valhalla:~/test] $ a.out 1
X ctor
X dtor