|Patches and status for old GMP releases|
N.B. Patches linked herein do not all carry a copyright header. This does not mean that we do not claim copyright, nor does it mean that we intend it to default to the "All rights reserved" status. The patches herein are under the LGPL 3.0 or later, see https://www.gnu.org/licenses/.
Issues with GMP 5.0.5:
Issues with GMP 5.0.4:
make check.These 11h processors are intermediates between K8 and K10, of sorts, in spite of that they have higher 'family' number than K10.
Issues with GMP 5.0.3:
Issues with GMP 5.0.2:
Issues with GMP 5.0.1:
make checkfailures. The problem is in mpn/pa64/aors_n.asm. Please download a new version of the file from the GMP repository.
Issues with GMP 5.0.0 (see also info about 5.0.1 above):
make checkfailures with t-constants. (3) There are issues with getting the compiler in 64-bit mode for some versions of Xcode. (The GMP developers don't have any x86 Mac for development or testing. Since every OS version is incompatible with every other OS version, and every Xcode version has its own requirements and quirks, one would probably need a whole array of Mac OS systems to maintain GMP well for this platform!)
Issues with GMP 4.3.2:
Issues with GMP 4.3.1 (see also info about 4.3.2 above):
Issues with GMP 4.3.0 (see also info about 4.3.1 above):
Issues with GMP 4.2.4:
mpz_perfect_power_pdoes not work correctly for negative arguments, but rejects many negative perfect powers. Patch
mpf_set_str(perhaps indirectly via
mpf_inp_str, or via the C++ interface) with the argument for the base set to 0, any exponent will be ignored. Patch
mpf_eqfunction sometimes compares too few bits, not just too many (the latter is documented). This might lead to precision loss. When the experimental --enable-nails feature is enabled at the same time --enable-cxx is enabled,
make checkfails. This failure is actually due to bugs in
tests/cxx/t-prec.cc, which makes it use
mpf_eqincorrectly. This patch makes
mpf_eqcompare the right number of bits, neither too few, nor to many. The patch also fixes the test case, and updates the documentation. Patch
Additional issues with GMP 4.2.3:
mpf_inp_stra number with a mantissa of larger precision than the destination variable, a buffer overrun may occur. The overrun can be arbitrarily large. The problem is a completely incorrect allocation in
mpf_set_str(in the file
mpf/set_str.c), where the destination variable's precision was used for an allocation that needed a size proportional to the string size. Patch
Additional issues with GMP 4.2.2:
mpf_inp_strwith a base > 36, the supplied base will actually be ignored, and the exponent 0 will be supplanted. Patch
Additional issues with GMP 4.2.1:
mpz_set_d, arguments smaller than 1e-19 will trigger undefined behaviour, typically a crash. Note that this is a somewhat degenerate use of
mpz_set_dthat should not normally happen, since any arguments < 1 will yield 0. Patch
mpn_popcountwill work unreliably when GMP is compiled with certain compilers. The symptom is segmentation fault. This is due to a GMP bug. Patch
mpn/generic/addsub_n.c. Second, GMP's build system passes options such as -march=athlon or -march=pentium4, and this can of course result in surprises for older processors. Patch [Updated 2006-06-12 to apply more smoothly]
Additional issues with GMP 4.2:
mpfoutput conversion yielding more than 2^31-1 digits will return only part of the digits. There are other problems with these routines when using the experimental nails feature. Patch
mpn_rootrem, affecting the user-level functions
mpz_perfect_power_p. The potential overrun is a function of input operand size, i.e., with large operands the overrun can be large. Patch
mpz_sizeinbasereturns garbage for operands greater than or equal to 2^31. The error is in
gmp-impl.h, which you need to patch. (Please note that operands of this size might trigger other problems in GMP; we will address this thoroughly for GMP 5.)
ABI=o32mode using the native SGI tools, the GMP
configuretest for an assembler underscore prefix fails. Pass
configureas a workaround.
mpf_subhas two problems. When the result is zero the exponent may not be zeroed, causing incorrect operation in subsequent operations such as
mpz_set_f. When high limbs cancel out, zeros at the top of the remainder are incorrectly counted towards the destination precision, causing a loss of accuracy and in particular possibly leading to a zero result when the operands are not equal. Patch for mpf/sub.c.
k6*-*-*), a bug in the assembler code may cause wrong results from
mpz_gcdand other functions using GCDs. Patch for mpn/x86/k6/gcd_finda.asm.
mpzroutines may give incorrect results due to gcc (version 3.3 for instance) not realizing that the profiler calls may clobber
regparmregisters. If profiling is desired then change gmp-impl.h to force
defined (PPC)from the two
#if's in that file.
powerpc*-apple-darwin7.2.0, a bug in the C library
sscanfaffects certain EOF returns from
gmp_sscanf, causing a failure in GMP tests/misc/t-scanf.c (line 1421). Hopefully Apple will fix this before too long. Past versions of Darwin have been ok.
substr()strings as arguments, due to lack of scalar magic handling in GMP.xs. For now the suggestion is to ignore the test.pl failures and to avoid passing substrings directly to the GMP module.
cc, the default flags don't include
-xarch=v8plusneeded for the GMP assembler code. Configure with
./configure CFLAGS="-xtarget=native -xarch=v8plus -xO4"
count_trailing_zerosin longlong.h may cause errors from the assembler about incorrect registers used with
make CC=g++" (in GMP.xs
class_or_croak, rename the
classvariable since that's a keyword in C++).
longoperand combinations may give incorrect results. Patch (applications must be recompiled).
FE_TOWARDZERO). Removing the offending cases will allow the library to build, though several test programs will fail.
doubleformat is not identified by gmp-impl.h, which can cause an MPFR build to fail. Patch.
mpz_gcd_uimay return a bad value when v==0 and u fits a limb but not a ulong. Patch.
doubleconstants being compiled incorrectly. This can cause an MPFR build to fail. Patch.
mpz_submulon Solaris 8 using a shared libgmp.so built by gcc 2.96 or higher may give incorrect results due to
regparmregisters being clobbered by lazy binding. This might arise on other i386 systems too, though a GNU system with GLIBC 2.1 or higher is known to be safe. Patch.
alphaev68, longlong.h uses GCC style
__asm__blocks without checking that GCC is being used. Patch.
./config.guessfor the exact OS type). Also
doublefloats are not correctly treated as big-endian; in gmp-impl.h move the
ieee_double_extractdown to the big-endian case. Also, the unbundled HP compilers coredump when compiling mpn/generic/mul_fft.c at high optimization levels; step into the mpn build directory and type "make CFLAGS=+O1 mul_fft.lo".
ABI=32build gets incorrect setups, resulting in asm files failing to build. In the generated
--enable-cxxon that system.
gcc_64_ldflags="-Wc,-m64"just after the v9
gcc_64_cflags, or alternately override at make time with
alphaev68a shared library may fail to build due to
__gmpn_clz_tab. Remove the
tests/mpz/t-sizeinbase.chas been seen failing on HPPA systems, due to some rash assumptions made about pointer arithmetic in that program. This can be ignored.
SCANF_OBJECTSnot defined. This is due to the trailing backslash on the end of the preceding
PRINTF_OBJECTS. Remove that from the generated
mpf_inp_strreturns an incorrect character count for valid input, and leaks memory for invalid input. Patch. (This problem has been present since 2.0.)
get_denreturn a special type which behaves like
mpz_class&but is not identical. An actual
mpz_class&can be obtained with this patch.
mpz_powm_uimay return a result outside the range 0 to m-1 in certain circumstances (e==1, abs(b)>m, m normalized). Patch. (This problem was present also in 4.0.)
.registerdirectives in mpn/sparc64/*.asm. Delete those lines if necessary.
alphaev56incorrectly selects just the ev4 code. Configure as
alphaev5for a speedup.
./configuredoesn't recognise the version number format used by GCC 3.1 on MINGW and Solaris, which can mean
-march=pentiumprois omitted unnecessarily. Patch.
t-scanffails on x86_64 systems, due to some sloppy varargs handling in that program. The library code as such is believed to be ok.
cmpfunctions described in the manual are in gmpxx.h as
compare. The line
__GMP_DEFINE_BINARY_TYPE_FUNCTION(int, compare, __gmp_cmp_function)can be edited to make it match the manual.
gmp_printfand friends have a bug affecting
%p. In printf/doprnt.c under
case 'p': case 's':, the
gmp_printfand friends are supposed to accept
size_toutput, but in printf/doprnt.c need a line
case 'z':added above the
gmp_scanf, and friends, incorrectly claim
size_tis unavailable when given
%zn. In printf/doprnt.c and scanf/doscan.c remove the
#if HAVE_SIZE_Tconditionals, leaving just the code for the "true" case.
<inttypes.h>. Change printf/doprnt.c, printf/repl-vsnprintf.c and scanf/doscan.c to use
#if HAVE_INTTYPES_H # include <inttypes.h> #else # if HAVE_STDINT_H # include <stdint.h> # endif #endif
libgmp.la: $(libgmp_la_OBJECTS) $(libgmp_la_DEPENDENCIES), apparently due to the length of the dependencies list. Either use GNU Make, or as a workaround remove
$(libgmp_la_DEPENDENCIES)from that line (which will make the initial build work, but if any recompiling is done libgmp.la might not be rebuilt at the right time).
-march=athlondoesn't know to use the zany
cmovsyntax required by the native assembler. This can affect GMP. The suggestion is either to use GNU binutils, or configure GMP with that flag downgraded to
-march=pentium, for example on a P-Pro, P-II or P-III
./configure CFLAGS="-g -O2 -fomit-frame-pointer -mcpu=pentiumpro -march=pentium".
ABI=64by default, but this will fail if the kernel is in 32-bit mode. Use
./configure ABI=32instead (in the future GMP will fall back to that automatically). But note that
ABI=64will give better performance, so consider rebooting into 64-bit mode (with
ok boot kernel/sparcv9/unix).
#include <strstream.h>uncommented. Either that or delete the unused
get_str2function which depends on it.
configuremay not automatically detect the correct CPU under cygwin and may guess i686 which is not a valid CPU. The suggested workaround is
"./configure --host=pentiumpro-pc-cygwin32"(with whatever CPU is approriate in place of pentiumpro).
mpq_equalmakes it fail if the first compared operand is negative. This patch corrects the problem. Joe Keane found the problem and wrote the patch.
mpf_get_strmake these functions segfault, and possibly generate incorrect results. This also affects
mpf_init_set_str. This gzip'ed patch fixes these errors.
mpz_invertmakes it sometimes return a negative result, and sometimes not detect when an inverse does not exist. Apply this patch to mpz/invert.c to fix this.
mpq_submakes them work unreliably due to references outside of allocated memory. Apply this patch to the mpq subdirectory to fix this.
CFLAGS="-g -O2 -mcpu=power"or
CFLAGS="-g -O2 -mcpu=powerpc"to `make' to work around this. (Choose the form that is appropriate for your system; if you're unsure which processor type you have, try running config.guess from the GMP top level directory.)
mpz_probab_prime_pmakes it work unreliably for numbers < 4. Apply this patch to mpz/pprime_p.c to fix the bug.
mpf_set_qmakes it get the sign wrong for negative numbers, and write to unallocated memory for other numbers. Apply this patch to mpf/set_q.c to fix the bugs.
mpn_divremmakes it occationally write outside of the numerator/remainder operand. Even if this function is called by several other GMP functions, only
mpf_set_strcall it in a way that risk to trigger the bug. Apply this patch to mpn/generic/divrem.c to fix the bug.
Some GNU/Linux distributions have a buggy ar program that omits many of the files from libgmp.a. As a result libgmp.a becomes useless. The best solution is to get a newer GNU release of binutils, version 2.6 or later. As a workaround, you could also apply this patch to the top-level directory of GMP 2.0.2, if you don't want to upgrade your GNU/Linux tools. The patch was written by Alexander Zimmermann.