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.
Replace CL_REQUIRE/CL_PROVIDE(cl_GV_I) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_GV_number) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_SV_number) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_SV_ringelt) with portable code.
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.
Get rid CL_REQUIRE/CL_PROVIDE(cl_fmt_scaleexp), it is not necessary.
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.
Remove CL_REQUIRE/CL_PROVIDE(cl_I_doublefactorial) as it's unnecessary.
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.
Remove CL_REQUIRE/CL_PROVIDE(cl_I_factorial) as it's not really necessary.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_MI) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_RA_ring) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_I_ring) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_R_ring) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_LF_globals) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_FF_globals) with portable code.
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).
Replace CL_REQUIRE/CL_PROVIDE(cl_DF_globals) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_C_ring) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_symbol) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_st_null) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_no_ring) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_random_def) with portable code.
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.
Replace CL_REQUIRE/CL_PROVIDE(cl_prin_globals) with portable code.
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.
replace CL_REQUIRE/CL_PROVIDE(cl_0_ring) with (more) portable code.
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.
Bruno Haible [Sat, 23 Feb 2008 18:06:32 +0000 (18:06 +0000)]
Change "make alls" and "make allo" to recurse into subdirectories.
* src/Makefile.in (alls-local): Renamed from alls.
(allo-local): Renamed from allo.
(SUBDIRS_TARGET_ALL): Renamed from SUBDIRS_TARGET.
(alls, allo): New rules.
(SUBDIRS_TARGET_ALLS, SUBDIRS_TARGET_ALLO): New variables.
Richard Kreckel [Mon, 4 Feb 2008 23:51:56 +0000 (23:51 +0000)]
Fix cl_F output of more than 2^32 decimal digits:
* src/base/string/cl_sstring.cc (cl_sstring): make len uintC.
* src/base/string/cl_sstring.h: Likewise.
Richard Kreckel [Sun, 6 Jan 2008 22:02:58 +0000 (22:02 +0000)]
Cater to the fact that g++ 4.3 will use a different naming for
the global constructor suffix in shared and static objects.
* m4/c++-constructors.m4 (CL_GLOBAL_CONSTRUCTORS): Add test for
the global constructor suffix, define CL_GLOBAL_CONSTRUCTOR_SUFFIX_PIC
and CL_GLOBAL_CONSTRUCTOR_SUFFIX_NOPIC appropriately.
* include/cln/config.h.in: Provide templates to be filled in by
configure.
* include/cln/modules.h (CL_PROVIDE, CL_REQUIRE): Use
CL_GLOBAL_CONSTRUCTOR_SUFFIX_PIC, CL_GLOBAL_CONSTRUCTOR_SUFFIX_NOPIC.
Richard Kreckel [Wed, 28 Nov 2007 22:45:51 +0000 (22:45 +0000)]
* include/cln/object.h: Don't redefine cl_word_alignment on sparc64.
* src/base/digitseq/cl_asm_sparc64_.cc: Declare use of global
register %g2 as scratch register within this file.
Reported by Paul Irofti <bulibuta@gmail.com> and Sven Verdoolaege
<skimo@kotnet.org>.
Richard Kreckel [Fri, 12 Oct 2007 21:44:21 +0000 (21:44 +0000)]
Fix compilation on CYGWIN:
* src/float/transcendental/cl_LF_zeta_int.cc: Avoid leading underscores
in variable names.
* src/float/transcendental/cl_LF_eulerconst.cc: Likewise.
Reported by Chris Bouchard <cbouchrd@uiuc.edu>.