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.
The only user of doublefakul_table array is doublefactorial function, so
put that array inside it in order to avoid possible static initialization
order problems.
factorial() is the only function which uses fakul_table[] array, so move
it into that function in order to avoid possible 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.
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.
While at it, remove work around for ancient (fixed in 8+ years) glibc/Linux
bug (the kernel and/or libc was initializing FPU into non-IEEE mode, so division
by 0 resulted in SIGFPE instead of NaN).
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.
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.
Alexei Sheplyakov
Richard Kreckel
Bruno Haible