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/>
Hi all: I have this example which output don't like me. #include <iostream> #include <cln/real.h> #include <cln/real_io.h> using namespace cln; int main(int argc, char **argv) { default_float_format=float_format(100); cl_R a,b; b=cl_float(1e-1,default_float_format); a=cl_float(1,default_float_format); a=a+b; std::cerr << "a=" << a << std::endl; } The output is: a=1.1000000000000000055511151231257827021181583404541015625L0 ^ ¿Why are here these noisy digits?. They are so close .. Gracias -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha@unex.es * * Teléfono: +34 924 289 300 Ext. 6826 Fax: +34 924 289 651 * *************************************************************************** * Usuario Linux: 8569 * * Para clave pública GnuPG: http://onsager.unex.es/firma.pub.asc * ***************************************************************************
Isidro Cachadiña Gutiérrez wrote:
b=cl_float(1e-1,default_float_format); a=1.1000000000000000055511151231257827021181583404541015625L0 ^ ¿Why are here these noisy
1e-1 is not the same as 0.1000000000000000000000000000000000000000000000000000000 See http://docs.sun.com/source/806-3568/ncg_goldberg.html for explanations. Bruno
participants (3)
-
Bruno Haible
-
Isidro Cachadiña Gutiérrez
-
Richard B. Kreckel