Hi! Ralf: I take this discussion to the mailing list in the hope that somebody there might have an idea. All others: Ralf and I were discussing a small experimental patch (see attachment) that balances all operator new and delete in order to please certain compilers. In particular, I added many no-op operator placement deletes. It also added some unimplemented declarations of private operator delete(void*) member functions to classes that had unimplemented private operator new(size_t). That patch had no effect on the code generated by GCC. However, the Intel compiler complained abaout four missing symbols: On Fri, 3 Dec 2004, Ralf Wildenhues wrote:
* Richard B. Kreckel wrote on Thu, Dec 02, 2004 at 10:17:20PM CET:
On Thu, 2 Dec 2004, Ralf Wildenhues wrote:
cl_SV_ringelt.o: cln::cl_SV_inner<cln::_cl_ring_element>::operator delete(void*) cl_SV_number.o: cln::cl_SV_inner<cln::cl_number>::operator delete(void*) cl_GV_number.o: cln::cl_GV_inner<cln::cl_number>::operator delete(void*) cl_GV_I.o: cln::cl_GV_inner<cln::cl_I>::operator delete(void*)
Bitte schick' mir mal die drei Dateien zum Disassemblen.
Hier sind die vier. :-)
Disassembling the four offending objects established the following (linear) call-graphs (not every symbol could be demangled by GNU objdump): cln::cl_svector_ringelt_destructor(cln::cl_heap*) cln::cl_heap_SV<cln::_cl_ring_element>::~cl_heap_SV() _ZN3cln10cl_heap_SVINS_16_cl_ring_elementEED9Ev cln::cl_SV_inner<cln::_cl_ring_element>::~cl_SV_inner() _ZN3cln11cl_SV_innerINS_16_cl_ring_elementEED9Ev cln::cl_SV_inner<cln::_cl_ring_element>::operator delete(void*) cln::cl_svector_number_destructor(cln::cl_heap*) cln::cl_heap_SV<cln::cl_number>::~cl_heap_SV() _ZN3cln10cl_heap_SVINS_9cl_numberEED9Ev cln::cl_SV_inner<cln::cl_number>::~cl_SV_inner() _ZN3cln11cl_SV_innerINS_9cl_numberEED9Ev cln::cl_SV_inner<cln::cl_number>::operator delete(void*) cln::cl_gvector_number_destructor(cln::cl_heap*) cln::cl_heap_GV<cln::cl_number>::~cl_heap_GV() _ZN3cln10cl_heap_GVINS_9cl_numberEED9Ev cln::cl_GV_inner<cln::cl_number>::~cl_GV_inner() _ZN3cln11cl_GV_innerINS_9cl_numberEED9Ev cln::cl_GV_inner<cln::cl_number>::operator delete(void*) cln::cl_gvector_integer_destructor(cln::cl_heap*) cln::cl_heap_GV<cln::cl_I>::~cl_heap_GV() _ZN3cln10cl_heap_GVINS_4cl_IEED9Ev cln::cl_GV_inner<cln::cl_I>::~cl_GV_inner() _ZN3cln11cl_GV_innerINS_4cl_IEED9Ev cln::cl_GV_inner<cln::cl_I>::operator delete(void*) The pattern is always the same, as is the code that triggers it. For example in cl_GV_I.cc: static void cl_gvector_integer_destructor (cl_heap* pointer) { (*(cl_heap_GV_I*)pointer).~cl_heap_GV_I(); } What I find irritating is that the dtors call their objects' operator delete(void*). Isn't that hazardous? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>