The épinards à la crème release.
MPFR 4.1.0 requires GMP 5.0 or higher.
Note: the bug-fix release MPFR 4.1.1 is available. Please upgrade!
The MPFR 4.1.0 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: 2021-05-17). 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. Because make's rebuild decisions are based on timestamps, the -Z option is highly recommended: it sets the modification time of the patched files from timestamps given in the patch file, thus avoiding unnecessary rebuilds that could need some development utilities (such as autoconf); for the special PATCHES file, this may generate a
Not setting timewarning, which you can safely ignore. If the -Z option is not available, you can also avoid the unnecessary rebuilds by using the --disable-maintainer-mode configure option later. 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.1 mpfr-4.1In 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:
_Decimal128
), conversions of double
to _Decimal128
yield an increase of 2 to 3 MB for the generated library code when the decimal encoding is BID (designed for software implementations), even though the conversions done in MPFR are very simple. Details about this GCC issue. The decimal128-conv patch avoids these conversions by directly using _Decimal128
constants. Note that fixing the issue entirely would require to get rid of all the decimal128 operations; in the mean time, decimal support (i.e. mpfr_get_decimal128
and mpfr_set_decimal128
functions) could be disabled at configure time.mpfr_set_z_2exp
function, a huge mpz_t
value can yield an integer overflow. This is fixed by the set_z_2exp-overflow patch (with testcases). Note that in practice, an integer overflow may occur only with a 32-bit ABI. Moreover, with a usual compilation, an integer overflow should here not yield any particular issue, assuming that the processor does signed addition and multiplication modulo 232 (as usual). However, UBsan would detect the overflow, and LTO might have unpredictable effects.mpfr_digamma
function needs to use an intermediate precision equal to the exponent of the input value, which may be huge. This is inefficient, and the code can request more memory than available, yielding a crash. The digamma-hugemem patch improves the implementation by making such a need much rarer; it also provides testcases showing a crash on 64-bit machines (at least).mpfr_digamma
function may have an erratic behavior in some cases (an assertion failure in debug mode). This is fixed by the digamma-interm-zero patch (with testcase).mpfr_j0
, mpfr_j1
, mpfr_jn
, mpfr_y0
, mpfr_y1
, mpfr_yn
) may have an erratic behavior in some cases (an assertion failure in debug mode). This is fixed by the jn-interm-zero patch (with testcase).mpfr_digamma
function may have an erratic behavior in some cases (an assertion failure in debug mode) when the reflection formula is used, i.e. when x < 1/2. This is fixed by the digamma-interm-zero2 patch (with testcase).mpfr_j0
, mpfr_j1
, mpfr_jn
, mpfr_y0
, mpfr_y1
, mpfr_yn
) may have an erratic behavior in some cases (an assertion failure in debug mode) when the asymptotic expansion is needed. This is fixed by the jyn_asympt-interm-zero patch (with testcase).mpfr_nan_p
, mpfr_inf_p
, mpfr_zero_p
, mpfr_regular_p
, mpfr_get_prec
, mpfr_get_exp
, mpfr_copysign
(third argument), mpfr_signbit
and mpfr_set
(second argument). For instance, providing an argument of type void *
instead of mpfr_ptr
or mpfr_srcptr
will yield a compilation failure. Note that this issue does not exist in C++, which does not support such implicit conversions. Moreover, the mpfr_set
macro evaluates its second argument twice (reported by David McCooey), which is incorrect if this evaluation has side effects. This is fixed by the macros patch (with testcases). Macros for the custom interface, which are explicitly documented as provided, do not follow these rules; the patch clarifies this point in the MPFR manual.MPFR_USE_NO_MACRO
is defined (e.g., via -DMPFR_USE_NO_MACRO
in CFLAGS). This is fixed by the tset_sij patch.mpfr_get_str_ndigits
function may raise the inexact flag. In a very reduced exponent range (e.g. in which the result would not be representable as a MPFR number), it has undefined behavior: it may return an incorrect value, crash, or loop, taking more and more memory. This is fixed by the get_str_ndigits patch, which also updates the tests to check these issues.mpfr_printf
, etc.) contains an incorrect assertion, checked only in debug mode, i.e. when MPFR has been configured with --enable-assert; this assertion failure occurs when the integer 0 (of either a native type or mpfr_prec_t
with the length specifier P) is output with the precision field equal to 0, i.e. when the corresponding string to output is empty. Otherwise, there should be no side effects since the code is actually valid in this case; but since the code incorrectly instructs the compiler that some variable cannot be 0, there might be an issue with some optimizations (very unlikely, though). This bug is fixed by the vasprintf-prec-zero patch, which also provides testcases.See the tracker and the BUGS file.
__float128
to the type _Float128
specified in ISO/IEC TS 18661. __float128
is used as a fallback if _Float128
is not supported.mpfr_get_str_ndigits
about conversion to a string of digits.mpfr_dot
for the dot product (incomplete, experimental).mpfr_get_decimal128
and mpfr_set_decimal128
(available only when MPFR has been built with decimal float support).mpfr_cmpabs_ui
.mpfr_total_order_p
for the IEEE 754 totalOrder predicate.mpfr_out_str
function now accepts bases from −2 to −36, in order to follow mpfr_get_str
and GMP's mpf_out_str
functions (these cases gave an assertion failure, as with other invalid bases).mpfr_printf
, etc.) with an empty precision field has improved: trailing zeros are kept in a way similar to the formatted output functions from C.mpfr_add
and mpfr_sub
when all operands have a precision equal to twice the number of bits per word, e.g., 128 bits on a 64-bit platform.mpfr_get_str
description in order to follow the historical behavior and GMP's mpf_get_str
function.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.1.0 has been successfully compiled and checked on the following platforms: