October 2007 - CLN-list

future GCC 4.3 and modules.h
by Ralf Wildenhues 10 Jan '08

10 Jan '08

Hello CLN people, Consider this code snippet: extern "C" void func () {} __asm__("\t.globl " "_GLOBAL__I_" "func"); static struct S { inline S () { } } S; On x86_64, with `g++-4.2 -fPIC -c a.cc', this results in | 0000000000000032 T _GLOBAL__I_func with mainline GCC (what will eventually be 4.3 or some other number), it has | 0000000000000032 t _GLOBAL__I_a.cc (and of course that will be `T' with the appropriate .globl directive). This affects .libs/cl_DF_globals.o and some of the other globals objects, and causes a link failure of the examples due to the CL_REQUIRE undefined references (global constructor keyed to ...). The hack below makes things work with mainline, but still needs to be redone properly, with a configure-time check and so on to not regress on g++ <= 4.2. If you like I can take a stab at writing so; I assume the test should make use of $lt_compiler_pic_CXX and the header file provide different defines based on whether -DPIC was given? (I'm not all that experienced with this stuff, so pointers are greatly appreciated.) Cheers, Ralf Index: include/cln/modules.h =================================================================== RCS file: /home/cvs/cln/include/cln/modules.h,v retrieving revision 1.19 diff -u -r1.19 modules.h --- include/cln/modules.h 7 May 2006 21:05:24 -0000 1.19 +++ include/cln/modules.h 26 May 2007 16:44:38 -0000 @@ -219,7 +219,7 @@ }; \ static _CL_REQUIRE_CLASSNAME(module,__LINE__) \ _CL_REQUIRE_CLASSNAME(module##_requirer,__LINE__); - #else + #elif 0 // gcc-3.0 -fuse-cxa-atexit doesn't have a single per-module destructor // function anymore. Instead, for each object's static constructor it // executes, it pushes the corresponding object's destructor onto a list. @@ -255,9 +255,42 @@ }; \ static _CL_REQUIRE_CLASSNAME(module,__LINE__) \ _CL_REQUIRE_CLASSNAME(module##_requirer,__LINE__); - #endif #define _CL_REQUIRE_CLASSNAME(module,line) __CL_REQUIRE_CLASSNAME(module,line) #define __CL_REQUIRE_CLASSNAME(module,line) cl_module__##module##__##line + #else + #define CL_PROVIDE(module) \ + extern "C" void cl_module__##module##__ctorend (void); \ + CL_GLOBALIZE_JUMP_LABEL(cl_module__##module##__ctorend) \ + CL_GLOBALIZE_CTORDTOR_LABEL( \ + ASM_UNDERSCORE_PREFIX CL_GLOBAL_CONSTRUCTOR_PREFIX \ + #module ".cc") \ + static int cl_module__##module##__counter; \ + struct cl_module__##module##__controller { \ + inline cl_module__##module##__controller () \ + { if (cl_module__##module##__counter++) \ + { CL_JUMP_TO(cl_module__##module##__ctorend); } \ + } \ + }; \ + static cl_module__##module##__controller cl_module__##module##__ctordummy; + #define CL_PROVIDE_END(module) \ + struct cl_module__##module##__destroyer { \ + inline cl_module__##module##__destroyer () \ + { CL_OUTPUT_LABEL (ASM_UNDERSCORE_PREFIX "cl_module__" #module "__ctorend"); } \ + }; \ + static cl_module__##module##__destroyer cl_module__##module##__dtordummy; + #define CL_REQUIRE(module) \ + extern "C" void cl_module__##module##__ctor (void) \ + __asm__ (ASM_UNDERSCORE_PREFIX CL_GLOBAL_CONSTRUCTOR_PREFIX \ + #module ".cc"); \ + struct _CL_REQUIRE_CLASSNAME(module,__LINE__) { \ + inline _CL_REQUIRE_CLASSNAME(module,__LINE__) () \ + { cl_module__##module##__ctor (); } \ + }; \ + static _CL_REQUIRE_CLASSNAME(module,__LINE__) \ + _CL_REQUIRE_CLASSNAME(module##_requirer,__LINE__); + #define _CL_REQUIRE_CLASSNAME(module,line) __CL_REQUIRE_CLASSNAME(module,line) + #define __CL_REQUIRE_CLASSNAME(module,line) cl_module__##module##__##line +#endif #else #define CL_PROVIDE(module) #define CL_PROVIDE_END(module)

3 15

Build problems on Solaris 8
by Robert W. Johnstone 16 Dec '07

16 Dec '07

Hello, I've tried building CLN 1.1.13 on a machine using Solaris 8. I'm having difficulty getting the library to pass all its tests. I've tried building CLN using gcc 4.1.1, with the following combinations of flags: "-O", "-O1", and "-O1 -fno-schedule-insns". The library fails many of the integer_floor_tests. I've attached the log from running tests/exam. Additionally, I've tried compiling with gcc 3.4.0 with the flags "-O -fno-schedule_insns". The library then fails sfloat_mul_tests 72 through 75. I'm uncertain what would be causing the errors. Thank-you, ---------------------------------------- Robert Johnstone Simon Fraser University http://www.sfu.ca/~rjohnsto/

3 4

problems building on powerpc64
by Dmitry Khutornoy 05 Dec '07

05 Dec '07

Hello! I got problems with building CLN on PowerPC64. uname -a Linux blade1 2.6.5-7.252-pseries64 #1 SMP Tue Feb 14 11:11:04 UTC 2006 ppc64 ppc64 ppc64 GNU/Linux make ... In file included from base/cl_N.h:6, from base/cl_as_err.cc:7: ../include/cln/number.h: In constructor `cln::cl_number::cl_number()': ../include/cln/number.h:191: error: `cl_FN_tag' undeclared (first use this function) ../include/cln/number.h:191: error: (Each undeclared identifier is reported only once for each function it appears in.) And it seems i know why does it happen: <config.h> ... #ifndef __powerpc64__ #define __powerpc64__ 1 #endif ... <object.h> ... #if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__sparc64__) || defined(__x86_64__) #define cl_word_alignment 8 #endif ... // Definition of the tags. #if !defined(CL_WIDE_POINTERS) #if (cl_word_alignment == 2) #define cl_FN_tag 1 #define cl_SF_tag 3 // must satisfy the cl_immediate_p predicate! #endif #if (cl_word_alignment == 4) #define cl_FN_tag 1 #define cl_SF_tag 2 #endif #else // CL_WIDE_POINTERS // Single Floats are immediate as well. #define cl_FN_tag 1 #define cl_SF_tag 2 #define cl_FF_tag 3 #endif There is no branch defining tags for powerpc64 (cl_word_alignment==8) Please, tell me what values should i write in #define or explain what am i doing wrong. Thank you! -- Best regards, Dmitry mailto:khutornoy@gmail.com

3 5

Bug in F_2[X] comparisson
by Remco Bloemen 04 Nov '07

04 Nov '07

Dear all, Lately i have been implementing a few algorithms from "Modern Computer Algebra". In the process of implementing Z[x] factorization i noticed the following strange behavior: cl_modint_ring basering = find_modint_ring(2); cl_univpoly_modint_ring ring = find_univpoly_ring(basering); cl_UP_MI x= ring->zero(); (x != ring->zero()) returns false (correct) (x == ring->zero()) returns false (incorrect) If i first compare x == x the behavior changes: (x == x) returns true (correct) (x != ring->zero()) returns true (incorrect) (x == ring->zero()) returns false (incorrect) Attached is a demonstrational program. I'm using cln version 1.1.13 compiled with gcc-4.2.2 on x86 (prescott). Could someone please tell me if this is fixed in cvs or being worked on?

3 5

Using CLN in Objective-C
by Ron Garret 30 Oct '07

30 Oct '07

I would like to use CLN in an Objctive-C project that makes use of the new garbage collector available in Mac OS X Leopard. Based on what I currently know, it seems like it should be a pretty straightforward task to create a thin wrapper in ObjC for CLN objects so that the CLN object is properly disposed of when the wrapper object is garbage collected. But I thought I would check with those of you who are more familiar with the guts of CLN to make sure that there aren't pitfalls that I ought to be aware of before I embark on this, and also to see if anyone besides me is interested in being able to use CLN for Leopard projects. Also, if anyone here has experience in both ObjC and CLN and is interested in some paid contract work related to this project please contact me off-line. rg

2 2

floating point underflow - a possible explanation
by Michael Schuster 29 Oct '07

29 Oct '07

Hi again, when thinking of my problem, I found the following (it's a bit talking to myself, but perhaps you can find it useful). + The problem with the underflow happens (at least in my case) because the declaration in fnCalc3() Real y2 = Real(string("-6.6061s14"));y Real wrapper class. makes a cl_SF out of y2. The other variable is cl_LF. It seems this causes the underflow. + Actually I thought, this problem can not occur - that's why I use the wrapper class, as I always use the double initialisation- But I found this: valarray<Real> c; c.resize(3); Real dd=c[0]; valarray will call default constructor which is Real():cl_F() and therefore produce a c[0] with type cl_SF. Ok, didnot think of that. My problem. Anyway with the following I get a lot of conversions then dd=Real(1.0/3.0); <<= cl_LF dd=Real(1.0/3.0)+c[0]; <<= back cl_SF again dd=c[0]+Real(1.0/3.0); <<= still cl_SF So once I have cl_SF in my system, it can be anywhere. So now I changed default constructor to Real():cl_F(cl_float(cl_I(0),float_format(_PRECISION_CLN_NEWMAT))) {}; and everthing seems ok now. To be absolutely sure I can change also Real(const cl_F &f):cl_F(cl_float(f,float_format(_PRECISION_CLN))) {} in my wrapper. (The string initialization is intentional.) Michael Watch this!! 1.49557e-52 Am Montag 29 Oktober 2007 schrieb Michael Schuster: > Hi Richy & Cln-List, > > Am Samstag 27 Oktober 2007 schrieb Richard B. Kreckel: > > In order for anyone to be able to help you it is essential that you > > write a reduced test case where the problem appears and can be > > investigated. > > Attachted I made a little demo programm which shows the problem. My output > is : > fnCalc1:1.49557e-52 > fnCalc2:1.49557e-52 > fnCalc2 + 0 :1.49557e-52 > fnCalc3:0 > Watch this!! 0 > Watch this!! 1.49557e-52 > > The line >>Watch this!! 0<< should be >>Watch this!! 1.49557e-52<< at > least in my mathematical opion. > > Ok, I donot know if my construct with the class Real is a possibile good > design. I wanted to have an easy possibility to switch from built-in-double > type to a class type with higher precision. > > Another problem is why I come (in my original programm) to a Real > value-type of cl_SF while I only use the Real base class with cl_float() > function as in the demo. But this is for next mailings here. > > My system: > $gcc --version > gcc (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux) > Copyright (C) 2005 Free Software Foundation, Inc. > Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es > gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE > ZWECKE. > > $rpm -q cln > cln-1.1.9-5 > > Thanks for any hint. > > Michael

2 1

floating point underflow
by Michael Schuster 29 Oct '07

29 Oct '07

Hi, I'm facing a problem using cöln (1.1.9 and 1.1.13) with my 32 Bit Linux-Athlon System here: I have expression like b+(a*a*a-a)*h/2 Some "a" are rather small, so I retrieve an underflow. I did inhibit this then, but the older version seems to stop calculation in a correct manner (results of other expressions in my programms can not be correct) and the newer says: "Internal error: statement in File ./float/elem/cl_F_mul.cc line 25 has been reached." Thanks for any hint Michael

2 2

Re: [CLN-list] CLN vs Cygwin [Was: cln compile error]
by cbouchrd＠uiuc.edu 19 Oct '07

19 Oct '07

Made suggested changes. Compiler appeared to make it past this point and crash in new spot. On-screen indications point to problem with generation of CLN documentation. I've attached compile.log.gz. Thanks for help to date. Regards, Chris ---- Original message ---- >Date: Thu, 18 Oct 2007 15:21:59 +0400 >From: Alexei Sheplyakov <varg(a)theor.jinr.ru> >Subject: Re: [CLN-list] CLN vs Cygwin [Was: cln compile error] >To: CLN discussion list <cln-list(a)ginac.de> > >Hello! > >On Tue, Oct 16, 2007 at 08:05:43PM -0500, cbouchrd(a)uiuc.edu wrote: > >> >Do you have the same problem when compiling static library only? i.e. >> >make clean &&./configure --disable-shared && make >> >> Yes. I've now compiled both ways and the on screen indications are identical. > >Could you please try this patch: > >[PATCH] zerop(cl_I& const): be more ISO C++ friendly. > >CLN's MAYBE_INLINE violates ISO C++, which demands (in 7.1.2.4) >"If a function with external linkage is declared inline in one translation >unit, it shall be declared inline in all translation units in which it >appears; no diagnostic is required." >This results in link errors on non-ELF platforms (MinGW, Cygwin, Darwin). >In particular, cl_I_ring.cc contains the following code: >extern bool zerop (const cl_I& x); // from <cln/integer.h> >inline bool zerop (const cl_I& x) // from cl_I.h >{ > return x.word == cl_combine(cl_FN_tag,0); >} > >static cl_number_ring_ops<cl_I> I_ops = { > cl_I_p, > equal, > zerop, // ... > >Since the address of zerop is taken here, the compiler is forced to emit >zerop function out-of-line. This results in duplicate symbols (which is >an error). > >--- > src/integer/ring/cl_I_ring.cc | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > >diff --git a/src/integer/ring/cl_I_ring.cc b/src/integer/ring/cl_I_ring.cc >index 416738a..fd96c12 100644 >--- a/src/integer/ring/cl_I_ring.cc >+++ b/src/integer/ring/cl_I_ring.cc >@@ -13,7 +13,9 @@ CL_PROVIDE(cl_I_ring) > > #include "cln/integer.h" > #include "cln/integer_io.h" >+#define zerop inline_zerop > #include "cl_I.h" >+#undef zerop > > namespace cln { > >@@ -34,10 +36,11 @@ static const _cl_ring_element I_zero (cl_heap_ring* R) > return _cl_ring_element(R, (cl_I)0); > } > >+static bool I_zerop (cl_heap_ring* R, const _cl_ring_element& x) __attribute__((flatten)); > static bool I_zerop (cl_heap_ring* R, const _cl_ring_element& x) > { > unused R; >- return zerop(The(cl_I)(x)); >+ return inline_zerop(The(cl_I)(x)); > } > > static const _cl_ring_element I_plus (cl_heap_ring* R, const _cl_ring_element& x, const _cl_ring_element& y) >-- >1.5.3.2 > >Best regards, > Alexei > >-- >All science is either physics or stamp collecting. > >________________ >signature.asc (1k bytes) >________________ >_______________________________________________ >CLN-list mailing list >CLN-list(a)ginac.de >https://www.cebix.net/mailman/listinfo/cln-list

1 0

Re: [CLN-list] CLN vs Cygwin [Was: cln compile error]
by cbouchrd＠uiuc.edu 18 Oct '07

18 Oct '07

Hi, Sorry for the delay... ---- Original message ---- >Date: Sat, 13 Oct 2007 19:17:13 +0400 >From: Alexei Sheplyakov <varg(a)theor.jinr.ru> >Subject: [CLN-list] CLN vs Cygwin [Was: cln compile error] >To: CLN discussion list <cln-list(a)ginac.de> > >Hello! > >On Fri, Oct 12, 2007 at 12:10:56PM -0500, cbouchrd(a)uiuc.edu wrote: > >> I have another compile issue, this time due to an apparent problem >> with undefined variables. > >Do you have the same problem when compiling static library only? i.e. >make clean &&./configure --disable-shared && make Yes. I've now compiled both ways and the on screen indications are identical. > >> I've attached two screen shots (with signifcant snipping between them) >> that may be useful. > >Unfortunately the text is almost unreadable (should I upgrade my >glasses?). Could you please send the compilation log instead? E.g. > >make 2>&1 | gzip -9 > compile.log.gz > >and post the compile.log.gz file. > The file is attached. >Best regards, > Alexei > >-- >All science is either physics or stamp collecting. > >________________ >signature.asc (1k bytes) >________________ >_______________________________________________ >CLN-list mailing list >CLN-list(a)ginac.de >https://www.cebix.net/mailman/listinfo/cln-list Thanks, Chris

2 1

Re: [CLN-list] cln compile error
by cbouchrd＠uiuc.edu 15 Oct '07

15 Oct '07

In "/cln/src/float/transcendental/cl_LF_zeta_int.cc" there are two occurrences of "_N" and two of "_s". I renamed both variables as you recommended and the error disappeared. I haven't encountered this problem again but I'm not done yet. I have another compile issue, this time due to an apparent problem with undefined variables. I've attached two screen shots (with signifcant snipping between them) that may be useful. I've also attached the config.log. Thanks again for any help! Regards, Chris Bouchard ---- Original message ---- >Date: Fri, 12 Oct 2007 16:44:57 +0200 >From: "Richard B. Kreckel" <kreckel(a)ginac.de> >Subject: Re: [CLN-list] cln compile error >To: CLN discussion list <cln-list(a)ginac.de> > >cbouchrd(a)uiuc.edu wrote: >> I'm getting a compile error similar to that reported in the Nov '07 thread of same subject name. I'm too ignorant, however, to apply the fix provided in that thread to my problem (if, in fact, it is applicable). >> >> I've included the config.log and a screen shot of the compile error. >> >> At first blush I thought the problem was in line 115 of "cl_LF_zeta_int.cc". After scanning the config.log and reading the old thread, though, it seems possible that the problem is within "confdefs.h" >> >> My operating system is Windows XP with CYGWIN. >> >> Thanks for any help. I look forward to using xloops/GiNaC/CLN in the near future! > >You are using a prerelease of CLN 1.2.0 from CVS and your compiler is >defining either _s or _N as some number. Can you, please, rename that >variable and try again? > >I wish to fix such things before the release of CLN 1.2.0, but I suspect >there are a number of other places where you'll have to apply the same >fix. Please, find them and send them to me (or this list). > >Thanks in advance > -richy. >-- >Richard B. Kreckel ><http://www.ginac.de/~kreckel/> >_______________________________________________ >CLN-list mailing list >CLN-list(a)ginac.de >https://www.cebix.net/mailman/listinfo/cln-list

4 5