- CLN-list - ginac.de

Aliasing rules and the -f[no-]strict-aliasing switches
by Richard B. Kreckel 14 Mar '05

14 Mar '05

Hi! Can anyone please explain what -f[no-]strict-aliasing and -W[no-]strict-aliasing do? (Yes, gcc accepts -Wno-strict-aliasing!) I'm experiencing some mild nausea because of type-punning in a library I'm maintaining. Gcc's documentation is not very clear, talking only about types being "almost the same". And unfortunately I have no copy of the holy standard lying around.. Also, Google appears to turn up only confused and confusing arguments, to this issue... :-( I was under the impression that pointers to some data structures are "almost the same", but apparently this is wrong: class Base { public: int x; }; class Derived : public Base { public: Derived() { x = 24; } virtual ~Derived() {} // (1) }; class Manager { public: union { void* pointer; Base* basepointer; }; }; #include <iostream> using namespace std; int main() { Derived* mp = new Derived; Manager obj; obj.pointer = mp; // (2) cout << mp->x << endl; cout << obj.basepointer->x << endl; } When compiled with GCC 3.x or 4.x, this results in: 24 134515352 With GCC 2.95, it resulted in: 24 24 Okay, removing the vtable in Derived (1) or adding one in Base (by adding a virtual dtor) appears to fix the program. Obviously, assigning to basepointer, as opposed to pointer (2) fixes it, too. But: As it stands, is the program really wrong? And: Why does -f[no-]strict-aliasing not make a difference. And should not -Wstrict-aliasing issue a warning? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 1

Floating point overflow for cl_R ln (const cl_R& x)
by Johnny Fundalewicz 09 Jan '05

09 Jan '05

Hi, I'm getting some floating point overflow errors when using logarithmic functionc l_R ln (const cl_R& x) with big Numbers ( > 20 Stellen). My code looks like this: -------------------------------- #include <cln/cln.h> int main(){ cln::cl_R number_one = "41234123412341234123157311812341234124312359123412341"; cln::cl_R number_two = cln::ln (number_one); std::cout << number_two << std::endl; return 0; } -------------------------------- I compiled with gcc-Version 3.3.5 (Debian 1:3.3.5-4): g++ -g -o test -lcln test.cpp Have I done a mistake or whats the reason why I can't compute those values - Is the number too large? I'm getting a floating point overflow and my debugger tells about 'Program exited with code 01' Or is there any other solution? Thx, Johnny

2 2

Compilation error:
by Isidro Cachadiña Gutiérrez 14 Dec '04

14 Dec '04

Hi again: Can be overloaded the + and - operators to compile these silly lines: cl_F a,b; a=1*b; a=1/b; and some like these? -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)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 * ***************************************************************************

2 4

More bugs.
by Isidro Cachadiña Gutiérrez 14 Dec '04

14 Dec '04

Hi again: Another silly program... #include <iostream> #include <cln/lfloat.h> #include <cln/lfloat_io.h> using namespace cln; int main(int argc, char **argv) { default_float_format=float_format(100); cl_LF a,b,c; b="1e-60"; a="1.0"; c=a+b; std::cerr << "c=" << c << std::endl; c=c-a; std::cerr << "c=" << c << std::endl; } And the outputs are 1.0L and 0.0L ¿What happen with the default_float_format?. If I write a="1.00000000000000000000000 ..." (100 zeros here) I obtain the same result, then b is lost somewhere. More, when b about < 1e-20 then it is lost. Maybe an error in the conversion? Bye. -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)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 * ***************************************************************************

2 6

Re: cln: ungeklärte Probleme (fwd)
by Richard B. Kreckel 10 Dec '04

10 Dec '04

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/>

3 2

DIGITS
by Isidro Cachadiña Gutiérrez 02 Dec '04

02 Dec '04

Hi all: Are there any way to declare all variables with a number digits for example, something like. funcion_foo (DIGITS); And then you are sure that all floating points variables are of number of decimal digits given by DIGITS. Thanks. -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)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 * ***************************************************************************

2 4

A silly program
by Isidro Cachadiña Gutiérrez 28 Nov '04

28 Nov '04

Hi All: I don't know if I'm wrong, but why are not defined elsewhere cln::operator-(const float , const cln::cl_R&) and some with double, etc. to compile this silly program. #include <cln/real.h> int main(int argc, char **argv) { cln::cl_F a,b; a=1; b=1.0-a; } -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)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 * ***************************************************************************

2 4

Types in cl_R
by Isidro Cachadiña Gutiérrez 20 Nov '04

20 Nov '04

Hi All: I am using cln with real numbers. I have a problem in the expt function... Wen I have, for example, #include <cln(/real.h> ... cl_R x,y,z; z=expt(x,y); I have problems with the prototypes defined in <real.h> that causes that expt cannot be used in this way. I also can define this function as: cln::cl_R expt(cln::cl_R x, cln::cl_R y) { return exp(x*ln(y)); } And It works fine, but I think that It have to be defined somewhere in the library. Cheers. -- *************************************************************************** * Dr. Isidro Cachadiña Gutiérrez * * Departamento de Física * * Facultad de Ciencias * * Universidad de Extremadura * * 06071 Badajoz ( SPAIN ) * * email: icacha(a)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 * ***************************************************************************

3 6

Re: [CLN-list] make failed on .libs/exam
by werner 05 Nov '04

05 Nov '04

ralf wrote: > I coult get rid of those by using the setarch tool and the > trivial patch below: > $ setarch i386 ../cln/configure -C 'CFLAGS=-m32 -g -O2' \ > 'CXXFLAGS=-m32 -g -O2' LDFLAGS=-m32 > $ setarch i386 make make failed with similar linker errors, the differences are: 1. additional undefined references to `_GLOBAL__I_cl_module__cl_ieee__firstglobalfun 2. the undefined references to mulu64_high and divu64_rest disappeared. btw, make without setarch i386 said exactly the same. installed cln on a pentium: no errors, make check passed, make install works. I couldn't use it to build GiNaC because I don't know how to tell GiNaC to find cln in my customized install dir, any hints? So I wrote a small sample program using cln: #include <iostream> #include <cln/real_io.h> #include <cln/random.h> #include <cln/real.h> using namespace std; using namespace cln; int main() { cl_R r=random_R(1.); cl_R s=exp(r); cout <<s <<endl; return 0; } and that worked on the x86. Then I copied libs and include to the xeon and compiled the program. With and without setarch i386, it complaint: .../cln/object.h:29: warning: "cl_word_alignment" redefined .../cln/number.h:187: error: `cl_FN_tag' undeclared .../cln/float_class.h:43: error: `cl_SF_tag' undeclared is this of any help? cheers werner

2 1

CLN 1.1.9 released
by Richard B. Kreckel 04 Nov '04

04 Nov '04

Good evening, It is my pleasure to announce the release of CLN 1.1.9. This is a maintenance release without any funky new features or any incompatibilities whatsoever. There is no reason for an immediate upgrade if you have been lucky with CLN 1.1.8. To quote NEWS file: Algorithmic changes ------------------- * Input of numbers in bases 2, 4, 8, 16 and 32 is now done in linear bit complexity as opposed to O(N^2). Useful for all kinds of persistency. Implementation changes ---------------------- * Fixed several bugs in the integer input and output routines that could be blamed for random crashes in the following cases: output in base 32 for quite large numbers, input in base 2 for fixnums and input in base 3 for fixnums on a 64 bit target. * Fixed crash when radix specifiers were used in input streams. * Speed up on x86_64 and ia64 by adding some inline assembly. Other changes ------------- * Fixes for compilation on MacOS X and little endian Mips. You may download the source tarball via anonymous FTP from <ftp://ftpthep.physik.uni-mainz.de/pub/gnu/cln-1.1.9.tar.bz2>. Happy hacking -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0