Reading leading '0' characters in integers of base 2, 4, 8, 16, or 32
could result in a NUDS with leading zero digits. This is against the
rules. The result was a misbehaving cl_I down the road.
Thanks to Morgan Deters <mdeters@cs.nyu.edu> of the CVC4 team.
The routine scale_float(cl_LF, cl_I) in file cl_LF_scale_I.cc had not
been adapted to 64-bit exponents on systems where uintD is 32 bit.
Reported by Michael Miller <millermj@lemoyne.edu>.
This patch works around problems MSVC has with extern "C" declarations
inside namespace cln. As a result, it should work with MS 32-bit compiler
version 16.00.30319.01.
Thanks to Jan Rheinländer <jrheinlaender@gmx.de>.
When we extended immediate types on 64-bit platforms back for CLN
1.2.0, we broke the assumption that integers 2^53..2^55-1 are
bignums. This lead to segfaults when approximating a non-integer cl_RA
to double, as reported by Igor Khavkine <igor.kh@gmail.com>.
Recent GMP multiplication routines (mpn_mul) are somewhat faster than CLN's.
For huge operands, this is due to better tuned FFT. For medium-sized operands
it's due to more algorithms (Toom 3-way.) For small operands, I couldn't find
a difference. Let's just use mpn_mul if it's available.
For huge binsplit sums, this can half the runtimes, on amd64.
Automake adds all kinds of subdirectories to -I, the list of directories
to be searched for header files. However, CLN's header files are not
supposed to be included without the cln/ subdirectory, so adding
-Iinclude/cln can lead to conflicts with other header files. (The
problem at hand was a conflict between CLN's string.h and the C
library's string.h).
Use std::iostream functions instead of EOF and cl_EOF macros.
This enables us to get rid of the freadchar and funreadchar functions.
While at it, removed the extra signatures introduced for CLN-1.2.0
compatibilty. After all, the soname has been bumped.
Also updated largest known Mersenne prime in examples/perfnum.cc.
src/base/cl_version.cc: don't #include "cl_sysdep.h", so the version info
actually gets compiled into the library.
Due to the changes introduced in 7da4d3ae ("build: switch to ordinary auto*
tools system") including "cln/version.h" after "cl_config.h" is no-op (yes,
this is intended).
Benefits:
1. If a header file gets modified, all dependent stuff gets rebuilt.
No need for 'make clean' after each header modification, no more
spurious errors, no more spurious rebuilds.
2. No more errors due to redefined preprocessor, compiler, and linker
FLAGS.
3. Build scripts don't try to build every *.cc file which happen to
lurk in the source directory.
Typical CLN source file starts with
// General includes.
#include "cl_sysdep.h"
// Specification.
#include "cl_2DS.h"
// Implementation.
#include "cl_2D.h"
#include "cl_DS.h"
It takes a while to figure out which files are included. So, use paths relative
to the `src' directory, like this:
// General includes.
#include "base/cl_sysdep.h"
// Specification.
#include "src/base/digitseq/cl_2DS.h"
// Implementation.
#include "base/digit/cl_2D.h"
#include "base/digitseq/cl_DS.h"
This makes CLN less hacker hostile.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Move static variables [SFDL]F_negative_epsilon into LF_negative_epsilon()
function (which is the only user of those variables) in order to avoid
possible static order initialization problems. While at it, make
LF_negative_epsilon() function static.
Move static variables [SFDL]F_epsilon into LF_epsilon() function (which
is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make LF_epsilon() function
static.
Move static variables least_negative_[SFDL]F into least_negative_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make least_negative_LF() function
static.
Move static variables least_positive_[SFDL]F into least_positive_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make least_positive_LF() function
static.
Move static variables most_negative_[SFDL]F into most_negative_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make most_negative_LF() function
static.
Move static variables most_positive_[SFDL]F into most_positive_LF() function
(which is the only user of those variables) in order to avoid possible static
order initialization problems. While at it, make most_positive_LF() function
static.
Turn cl_[SDFL]F_catalanconst global variables into functions (which return
a reference to the static value) in order to avoid static initialization
order problems.
Turn cl_[SDFL]F_eulerconst global variables into functions (which return
a reference to the static value) in order to avoid static initialization
order problems.
Turn cl_[SDFL]F_exp1 global variables into functions (which return a reference
to the static value) in order to avoid static initialization order problems.
Turn cl_[SDFL]F_ln10 global variables into functions (which return a constant
reference to the static value) in order to avoid static initialization order
problems.
Turn cl_[SDFL]F_ln2 global variables into functions (which return a constant
reference to the static value) in order to avoid static initialization order
problems.
Turn cl_[SDFL]F_pi global variables into functions (which return a constant
reference to the static value) in order to avoid static initialization order
problems.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
The order of initialization of non-local objects in different compilation units
is not specified in C++. Hence special care should be taken to avoid static
initialization order fiasco. CLN solved the problem with some evil (GCC
specific, and even GCC-version-specific) hack. Replace it with a technique
similar to one used in STL to initialize std::cout and friends.
Move a bunch of static objects (tenth, SF_zero, FF_zero, etc) into
the function get_float_params (which is the only user of those variables)
in order to avoid possible static order initialization problems.
Richard Kreckel
Alexei Sheplyakov