I was just comparing the configuration differences for these two platforms:
HP-UX B.11.21/HP aCC 3.73 HP-UX B.11.31/HP aCC 6.16 See http://people.apache.org/~elemings/diff.out. There seems to be way to many configuation differences. I think we may have a much more serious problem on HP-UX ia64. Brad. > -----Original Message----- > From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor > Sent: Friday, March 21, 2008 5:10 PM > To: [email protected] > Subject: Re: [STDCXX-709] ContainerData ctor and > UserClass::from_char() > > Eric Lemings wrote: > > > > > >> -----Original Message----- > >> From: Martin Sebor [mailto:[EMAIL PROTECTED] > >> Sent: Friday, March 21, 2008 3:32 PM > >> To: [email protected] > >> Subject: Re: [STDCXX-709] ContainerData ctor and > >> UserClass::from_char() > >> > > ... > >> So you think there's a mismatch between the allocation function > >> invoked in value.cpp and the deallocation function called in the > >> header? Why would that be? IIUC, tests that replace operator new > >> and operator delete (such as 23.list.assign) replace it for the > >> whole process. If there's a mismatch, it can only be because > >> the operators aren't replaced consistently. Making sure this > >> replacement happens across the whole process, including any > >> libraries, is the responsibility of the C++ runtime (i.e., > >> the compiler). If your analysis is correct, the C++ runtime > >> on IPF would have to be buggy. > >> > >> Or did I misunderstand what you were trying to say? > > > > Sounds about right. > > > > I just noticed there's a runtime link error in the config test > > OPERATOR_NEW_ARRAY_PLACEMENT on HP-UX IPF platforms. May be the > > culprit. > > > > [EMAIL PROTECTED] ./include/OPERATOR_NEW_ARRAY_PLACEMENT > > /usr/lib/hpux32/dld.so: Unsatisfied code symbol '_ZnamPv' in load > > module './stdcxx/include/OPERATOR_NEW_ARRAY_PLACEMENT'. > > Killed > > That's a check for placement new in the runtime library. I don't > think that has any bearing on the replaceability of operator new. > > I.e., the first one is not replaceable: > > void* operator new(size_t, void*) throw(); > void* operator new[](size_t, void*) throw(); > > while the second one is: > > void* operator(size_t) throw (bad_alloc); > void* operator[](size_t) throw (bad_alloc); > > The first form is usually defined inline in <new>, like so: > > inline void* operator new(size_t, void *ptr) throw() { > return ptr; > } > > and so it's not defined in the runtime library. That's why I assume > the OPERATOR_NEW_ARRAY_PLACEMENT test fails: it declares the operator > and calls it without providing a definition to see if one exists in > the runtime. Unless the test finds one we need to provide our own > definition in our <new>. Otherwise we just declare it. > > Martin >
