![[MPFR]](../mpfr100.png){kind=small}
The épinards à la crème release.
MPFR 4.1.0 requires GMP 5.0 or higher.
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. 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.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: