![[MPFR]](../mpfr100.png){kind=small}
The dinde aux marrons release, patch level 1.
MPFR 4.0.1 requires GMP 5.0 or higher.
Note: the bug-fix release MPFR 4.0.2 is available. Please upgrade!
Warning! Due to the fact that
TLS support is now detected
automatically, the MPFR build can be incorrect on some
platforms (compiler or system bug). Indeed,
the
TLS implementation of some compilers/platforms is buggy,
and MPFR cannot detect every problem at configure time.
Please run make check
to see if your build is affected.
If you get failures, you should try the --disable-thread-safe
configure option to disable TLS and see if this solves
these failures. But you should not use an MPFR library
with TLS disabled in a multithreaded program (unless
you know what you are doing).
The MPFR 4.0.1 source can be downloaded in the following archive formats:
Each tarball is signed by Vincent Lefèvre. This can be verified using the DSA key ID 980C197698C3739D; this key can be retrieved with:
gpg --recv-keys 980C197698C3739D
or by downloading it from https://www.vinc17.net/pgp.html. The key fingerprint is:
07F3 DBBE CC1A 3960 5078 094D 980C 1976 98C3 739D
The signatures can be verified with:
gpg --verify file.asc
You should check that the key fingerprint matches.
MPFR is also available via third-party packages and ports.
The bugs listed below have been fixed (latest update: 2019-01-31). The patches are distributed under the same license as this version of MPFR, that is, the GNU Lesser General Public License (GNU Lesser GPL), version 3 or later.
The following instructions are for Linux and may be similar for other operating systems. You can apply the patches in several ways:
patch -N -Z -p1 < path_to_patches_filefrom the source directory. The -N option allows the patch command to ignore patches already applied. The -Z option sets the modification time of the patched files from time stamps given in the patch file, thus avoiding the need of some development utilities (such as autoconf); this may generate a
Not setting timewarning for the PATCHES file, but you can safely ignore it. Under Microsoft Windows, in addition to the above options, you may need the --binary option (this depends whether the end-of-lines have been converted when you downloaded the patch file). Also note that the --dry-run option does not work if the cumulative patch has some file listed several times.
svn co https://scm.gforge.inria.fr/anonscm/svn/mpfr/branches/4.0 mpfr-4.0In this case, as said on the Gforge page, you should read the README.dev file for details on how to build MPFR. Also note that the branch may contain additional minor fixes.
With the first two ways, the PATCHES file is modified,
so that one can know what patches have been applied, using the
mpfr_get_patches function. Moreover a suffix is added to
the version string, but note that for practical reasons, not all the
files where the version appears are patched; thus one can also track
applied patches with the MPFR_VERSION_STRING macro (header)
and the mpfr_get_version function (library). However, if
some patches are not applied or if patches are applied in a different
order, then the patch command will fail to update some chunks, so that
the suffix is not always reliable for patches.
Note: These patches are in unified diff format and some vendors' patch commands cannot deal with them; in this case, please use GNU patch (it may already be installed on your system, e.g. as /usr/local/bin/patch or gpatch).
Fixed bugs, with patches:
GMP_NUMB_BITS bits of precision (typically, 32 bits on 32-bit machines, 64 bits on 64-bit machines). Other functions doing such a subtraction might be affected as a consequence, but no failures are known yet. This bug, which was introduced in MPFR 4.0.0, is fixed by the sub1sp1n-reuse patch, which also provides testcases.mpfr_fma and mpfr_fms functions can behave incorrectly in case of internal overflow or underflow. This bug is fixed by the fma patch (with a complete rewrite of these cases), which also provides testcases.mpfr_sqr function can be rounded incorrectly in a rare case near underflow when the destination has exactly GMP_NUMB_BITS bits of precision (typically, 32 bits on 32-bit machines, 64 bits on 64-bit machines) and the input has at most GMP_NUMB_BITS bits of precision. This bug, which was introduced in MPFR 4.0.0, is fixed by the sqr_1n-underflow patch, which also provides testcases.mpfr_get_str function are inconsistent concerning the minimum precision (this is related to the change of the minimum precision from 2 to 1 in MPFR 4.0.0). The get_str patch fixes this issue in the following way: the value 1 can now be provided for n (4th argument of mpfr_get_str); if n = 0, then the number of significant digits in the output string can now be 1, as already implied by the documentation (but the code was increasing it to 2). This patch fixes both the code and the manual, and provides testcases.mpfr_cmp_q function can behave incorrectly when the rational (mpq_t) number has a null denominator; note that such rational numbers are not canonical, thus cannot be generated by GMP (they are supported by MPFR to represent infinities and NaN with mpq_t). This bug is fixed by the cmp_q-special patch, which also provides testcases.mpfr_inp_str and mpfr_out_str functions might behave incorrectly when the stream is a null pointer: the stream is replaced by stdin and stdout, respectively. This behavior is useless, not documented (thus incorrect in case a null pointer would have a special meaning), and not consistent with other input/output functions. This is fixed by the io-null-stream patch (no testcases are provided since in general, a null pointer is invalid for input/output).long * (the code ensures alignment to long, which GCC is not able to take into account). These warnings are avoided by the tstckintc-casts patch, which still allows checks of other alignment requirements (not handled by the tstckintc.c code), as explained in a comment in the patch.mpfr_set_decimal64 is always 0. This bug is fixed by the set_d64-ternary patch, which also provides testcases.buffer_sandwich used by the formatted output functions (mpfr_*printf) to handle the ' flag in locales where the thousands separator is not empty has several bugs. The main one, which could have visible consequences in practice: In some specific cases (that is, when the integer part is rounded upward to 10 or 100), the generated string can be incorrect and since it is shorter than expected, an incorrect buffer size may be provided to the freefunction of the current GMP memory allocator. By default, this size is ignored, but it may matter if the memory allocators have been changed with the
mp_set_memory_functions GMP function, in which case a possible consequence could be memory corruption. These bugs are fixed by the buffer_sandwich patch, which also provides testcases.mpfr_erf and mpfr_erfc functions can yield an assertion failure due to the fact that the error bound is computed with the double type and can overflow. This bug is fixed by the erf patch, which also provides testcases.mpfr_prec_t argument); this includes the sign of the field width when the value is provided in argument (by using an asterisk * in the format string). This bug is fixed by the vasprintf-p-length-modifier patch, which also provides testcases.mpfr_set_1_2 can round in the wrong direction in case of double rounding. This bug can affect only the functions mpfr_fmma and mpfr_fmms in rounding to nearest (MPFR_RNDN), and only when their mpfr_t arguments all have a same precision p ≥ GMP_NUMB_BITS (the number of bits per limb): under these conditions, if ab±cd rounded to 2p bits is the middle of two consecutive p-bit numbers (i.e., it is representable on p+1 bits but not on p bits), then these functions mpfr_fmma and mpfr_fmms can round in the wrong direction. This bug is fixed by the set_1_2 patch, which also provides testcases (it also simplifies the generic algorithm, avoiding non-portable code).mpfr_strtofr function has various issues. In particular, the error analysis with associated code was incorrect (due to the bad correction b87d760d (r8384) of a past bug, later really fixed in 6b2928f5 (r11056)). The strtofr patch, which also provides testcases, attempts to fix these issues. But the code has not been fully checked yet.Bugs fixed in the 4.0 branch for the future MPFR 4.0.2 release:
__float128 support at configure time, MPFR may detect __float128 as working (supported by the compiler), while a failure occurs at link time, such as under NetBSD. The test has now been improved so that one does not need an explicit --disable-float128 configure option in such a case.mpfr_get_str function is slightly incorrect and incomplete: for the argument b (the base), values from −2 to −36 are actually allowed. The manual has been corrected and completed, following the historical behavior and GMP's mpf_get_str function.See also the tracker and the BUGS file.
__GMP_CC and __GMP_CFLAGS retrieval (in particular for MS Windows).mpfr_div_ui, which could yield an incorrectly rounded result to nearest when using different precisions; this bug had been present since the introduction of mpfr_div_ui, and in MPFR 4.0.0, it was affecting mpfr_div too.make check-exported-symbols, mainly for the MPFR developers and binary distributions, to check that MPFR does not define symbols with a GMP reserved prefix (experimental).
MPFR 4.0.1 has been successfully compiled and checked on the following platforms:
__float128 as being unsupported).