- CLN-list - ginac.de

compiler errors with intel c++
by Tamas Istvan 21 Aug '11

21 Aug '11

Hello, When I make the cln lib with Intel C++ compiler, it gives the following error messages: /bin/sh ../libtool --tag=CXX --mode=compile icpc -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -O2 -xAVX -axAVX -parallel -vec-report -MT cl_C_cis.lo -MD -MP -MF .deps/cl_C_cis.Tpo -c -o cl_C_cis.lo `test -f 'complex/transcendental/cl_C_cis.cc' || echo './'`complex/transcendental/cl_C_cis.cc libtool: compile: icpc -DHAVE_CONFIG_H -I. - I../autoconf -I../include -I../src -I../include -I../src -O2 -xAVX -axAVX -parallel -vec-report -MT cl_C_cis.lo -MD -MP -MF .deps/cl_C_cis.Tpo -c complex/transcendental/cl_C_cis.cc -fPIC -DPIC -o .libs/cl_C_cis.o complex/transcendental/cl_C_cis.cc(24): error: argument is incompatible with formal parameter var cos_sin_t trig = cos_sin(x); ^ complex/transcendental/cl_C_cis.cc(31): error: argument is incompatible with formal parameter var cos_sin_t trig_a = cos_sin(a); // cos(a), sin(a) errechnen ^ compilation aborted for complex/transcendental/cl_C_cis.cc (code 2) make[1]: *** [cl_C_cis.lo] Error 1 make[1]: Leaving directory `/home/cln-1.3.2/src' make: *** [all-recursive] Error 1 Slackware Linux 64bit Kernel version 2.6.37.6 Intel i5-2400 proc. Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 12.0.4.191 Build 20110427 Copyright (C) 1985-2011 Intel Corporation. Added compiler options: -O2 -xAVX -axAVX -parallel -vec-report What can I do to correct this? Thanks. Tamas Istvan

2 1

CLN 1.3.2 has been released
by Richard B. Kreckel 08 May '11

08 May '11

Hi! This release fixes a bug on x86 when the scale factor of scale_float(cl_LF, cl_I) exceeded 2^31. In addition, it improves portability to non-GCC compilers. Download it from the usual place: <http://www.ginac.de/CLN/>. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

Upcoming release
by Richard B. Kreckel 01 May '11

01 May '11

Hi! Later this weekend I plan to fix the problem with scale_float on x86 reported by Michael Miller and then release CLN 1.3.2 in a couple of days. Could someone please check whether the problems on MSVC have been sorted out in current master HEAD? They should, after a recent commit, but I cannot test it. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

3 6

CLN patch 3 for MSVC
by Jan 14 Mar '11

14 Mar '11

Hi, here is a simple one correcting some unclear code (at least from the point of view of the pedantic MSVC compiler). 1. Added const because the original declaration in the header file also has it 2. Added double to resolve ambiguities in which log() function is meant With this patch and the two others I sent earlier CLN compiles with MSVC and all tests pass successfully. Jan

2 2

CLN MSVC Patch 2
by Jan 12 Mar '11

12 Mar '11

Hi, here is another exasperating patch: If I compile the following code with MSVC (taken from number.h, I only added the extra qualification cln:: to illustrate the problem) namespace cln { inline _class_::_class_ (const unsigned long wert) { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); pointer = cln::cl_I_constructor_from_UL(wert); } } then I get the following error: ./include\cln/number.h(230) : error C2039: 'cl_I_constructor_from_UL' : is not a member of 'cln' and of course without the cln:: qualification I get linker errors for unresolved symbols because in cl_I_from_UL.cc the function is clearly defined inside the cln namespace. If I change the code to namespace cln { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); inline _class_::_class_ (const unsigned long wert) { pointer = cln::cl_I_constructor_from_UL(wert); } the errors disappear. I know that it is not desirable to move the extern declaration outside of the function body. But for MSVC this appears to be the only way to force the compiler to put it into the cln namespace. Therefore I would propose the following patch for MSVC only: // At the beginning of the file #ifdef _MSC_VER namespace cln { extern cl_private_thing cl_I_constructor_from_UL (uint32 wert); } #endif and the extra cln:: qualification as shown above. This is the solution with the smallest changes. But of course it would also be possible to create two versions of the inline functions and choose the right one with _MSC_VER. Please give me your opinions before I start any big edits. Thanks, Jan

1 0

Floating point overflow discrepancy
by Michael Miller 28 Feb '11

28 Feb '11

The following code (to calculate x^100000): cl_R x="1.0L100000", y=1; for (int i=1; i<=100000; i++) y=x*y; cout << y << "\n"; cout << exp(100000*ln(x)) << "\n";; results in the output 1.00000000000000302104L10000000000 terminate called after throwing an instance of 'cln::floating_point_overflow_exception' what(): floating point overflow. Aborted I know that these are very large numbers, but the two calculations are computing the same value. If the first doesn't overflow, then why does the second? Mike

2 3

Re: [CLN-list] CLN extern "C" patch
by Richard B. Kreckel 15 Feb '11

15 Feb '11

Hi! On 02/15/2011 09:45 AM, Jan wrote: > as far as I know there is no version of MSVC that compiles CLN without > problems to date. I am working on it... Has a bugreport been submitted to the compiler manufacturer regarding this nonconformity with the standard? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

1 0

CLN patch 1
by Jan private 15 Feb '11

15 Feb '11

Problem: MSVC creates different symbol names for 'extern "C" uint32 mulu32_high' when declared inside the cln namespace, and when defined inside it. Linking produces "unresolved external symbol" errors. ----- Which is allowed by the Standard (specifically, [dcl.link]). However, it also says: "At most one function with a particular name can have C language linkage. Two declarations for a function with C language linkage with the same function name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same function. Two declarations for an object with C language linkage with the same name (ignoring the namespace names that qualify it) that appear in different namespace scopes refer to the same object. [Note: because of the one definition rule (3.2), only one definition for a function or object with C linkage may appear in the program; that is, sucha function or object must not be defined in more than one namespace scope." ----- Solution: Moved declarations into global namespace and prefixed with cln_

4 6

mingw-w64
by Jan 08 Feb '11

08 Feb '11

Hi, I tried to compile CLN with MinGW 64-bit (compilation for 32bit works fine). Downloaded mingw-w64-1.0-bin_i686-linux_20110117.tar.bz2 from sourceforge and installed it. git clone git://www.ginac.de/cln.git cd cln autoreconf -i ./configure --host=x86_64-w64-mingw32 --prefix=/usr/x86_64-w64-mingw32 --without-gmp make and this is the result (complete output): Making all in src make[1]: Entering directory `/home/jan/mingw/cln/src' /bin/bash ../libtool --tag=CXX --mode=compile x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -g -O2 -MT cl_alloca.lo -MD -MP -MF .deps/cl_alloca.Tpo -c -o cl_alloca.lo `test -f 'base/cl_alloca.cc' || echo './'`base/cl_alloca.cc libtool: compile: x86_64-w64-mingw32-g++ -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -g -O2 -MT cl_alloca.lo -MD -MP -MF .deps/cl_alloca.Tpo -c base/cl_alloca.cc -o cl_alloca.o In file included from ./base/cl_sysdep.h:10:0, from base/cl_alloca.cc:4: ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into a long!!" In file included from ../include/cln/types.h:10:0, from ./base/cl_macros.h:6, from ./base/cl_sysdep.h:56, from base/cl_alloca.cc:4: ../include/cln/intparam.h:26:2: error: #error "Type char * does not fit into a long!!" base/cl_alloca.cc: In function 'cln::cl_alloca_header* cln::cl_alloc_alloca_header(size_t)': base/cl_alloca.cc:20:40: error: cast from 'long int*' to 'long int' loses precision make[1]: *** [cl_alloca.lo] Error 1 make[1]: Leaving directory `/home/jan/mingw/cln/src' make: *** [all-recursive] Error 1 Any ideas? Thanks, Jan

3 5

[patch] fix compile errors with clang
by Pawel Worach 02 Feb '11

02 Feb '11

Hi, Here are two patches to fix compile errors with clang. libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I../autoconf -I../include -I../src -I../include -I../src -I/usr/local/include -O2 -pipe -fPIC -fno-strict-aliasing -MT cl_rcpointer2_hashweak_rcpointer.lo -MD -MP -MF .deps/cl_rcpointer2_hashweak_rcpointer.Tpo -c base/hash/cl_rcpointer2_hashweak_rcpointer.cc -fPIC -DPIC -o .libs/cl_rcpointer2_hashweak_rcpointer.o In file included from base/hash/cl_rcpointer2_hashweak_rcpointer.cc:7: In file included from ./base/hash/cl_rcpointer2_hashweak_rcpointer.h:8: In file included from ./base/hash/cl_hash2weak.h:6: ./base/hash/cl_hash2.h:121:13: error: use of undeclared identifier '_garcol_fun' if (_garcol_fun(this)) ^ this-> ./base/hash/cl_hash2.h:77:9: note: in instantiation of member function 'cln::cl_heap_hashtable_2<cln::cl_rcpointer, cln::cl_rcpointer, cln::cl_rcpointer>::prepare_store' requested here prepare_store(); ^ base/hash/cl_rcpointer2_hashweak_rcpointer.cc:47:67: note: in instantiation of member function 'cln::cl_heap_hashtable_2<cln::cl_rcpointer, cln::cl_rcpointer, cln::cl_rcpointer>::put' requested here ((cl_heap_weak_hashtable_from_rcpointer2_to_rcpointer*)pointer)->put(x,y,z); ^ In file included from base/hash/cl_rcpointer2_hashweak_rcpointer.cc:7: In file included from ./base/hash/cl_rcpointer2_hashweak_rcpointer.h:8: In file included from ./base/hash/cl_hash2weak.h:6: In file included from ./base/hash/cl_hash2.h:6: ./base/hash/cl_hash.h:36:12: note: must qualify identifier to find this declaration in dependent base class bool (*_garcol_fun) (cl_heap*); // Function to make room in the table. ^ 1 error generated. --- src/base/hash/cl_hash2.h.orig 2009-05-10 22:32:30.000000000 +0200 +++ src/base/hash/cl_hash2.h 2011-01-30 01:59:01.000000000 +0100 @@ -118,7 +118,7 @@ if (this->_freelist < -1) return; // Can we make room? - if (_garcol_fun(this)) + if (this->_garcol_fun(this)) if (this->_freelist < -1) return; // No! Have to grow the hash table. @@ -126,7 +126,7 @@ #else // workaround Sun C++ 4.1 inline function compiler bug if (this->_freelist >= -1) { - if (!_garcol_fun(this) || (this->_freelist >= -1)) + if (!this->_garcol_fun(this) || (this->_freelist >= -1)) grow(); } #endif --- src/base/hash/cl_hashuniq.h.orig 2011-01-30 01:57:23.000000000 +0100 +++ src/base/hash/cl_hashuniq.h 2011-01-30 01:58:31.000000000 +0100 @@ -115,7 +115,7 @@ if (this->_freelist < -1) return; // Can we make room? - if (_garcol_fun(this)) + if (this->_garcol_fun(this)) if (this->_freelist < -1) return; // No! Have to grow the hash table. @@ -123,7 +123,7 @@ #else // workaround Sun C++ 4.1 inline function compiler bug if (this->_freelist >= -1) { - if (!_garcol_fun(this) || (this->_freelist >= -1)) + if (!this->_garcol_fun(this) || (this->_freelist >= -1)) grow(); } #endif -- Pawel

2 1