![[MPFR]](../mpfr100.png){kind=small}
The boudin aux pommes release.
MPFR 3.0.0 requires GMP 4.1.0 or higher (GMP 4.2.3 or higher is recommended).
Note: the bug-fix release MPFR 3.0.1 is available. Please upgrade!
The MPFR 3.0.0 source can be downloaded in the following archive formats:
MPFR is also available via third-party packages and ports.
The bugs listed below have been fixed (latest update: 2010-11-10). 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 with this cumulative patch.
svn co svn://scm.gforge.inria.fr/svn/mpfr/branches/3.0 mpfr-3.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:
mpfr_out_str
function is incorrect on NaN and infinities. Moreover output errors
are not handled, and if such an error occurs, the return value is
incorrect (it should have been 0). These bugs are fixed by the
mpfr_out_str patch (which also
provides additional tests of mpfr_out_str).HAVE_ALLOCA_H is not defined. This problem has been
introduced in MPFR 3.0.0.
It is fixed in the alloca patch.mpfr_gamma is incorrect.
A possible consequence is that the function can freeze. This bug is fixed
by the gamma_underflow patch (which also
provides a testcase for 32-bit machines).In the mpfr_cmp_ui macro for
GCC-based compilers, when the second argument is a
constant expression with the value 0, the first argument is evaluated
twice, making the behavior incorrect when the evaluation of the first
argument yields side effects. The mpfr_cmp_si macro uses
mpfr_cmp_ui, thus is also affected by this bug. Note that
though mpfr_cmp_ui and mpfr_cmp_si are described
as functions, they are also implemented as macros in mpfr.h
(except in case of a bug like here, a macro implementation should
not introduce a difference in the behavior).
A much less important problem is that the mpfr_cmp_si and
mpfr_set_si macros for GCC-based compilers
(from mpfr.h) can yield warnings when user code is compiled
with the -Wconversion option.
These macros mpfr_cmp_ui, mpfr_cmp_si,
mpfr_set_ui and mpfr_set_si for
GCC-based compilers can have an incorrect behavior if
user code with undefined behavior requires to behave according to some
non-standard C extension (like with the use of the -fwrapv
GCC option) and the call is done with an argument
that requires an implicit conversion to unsigned long or
long.
All these problems are fixed by the mpfr_cmp/set_ui/si patch (which also provides a testcase for the first problem).
mpfr_prec_t type is signed.
This problem is fixed by the tcan_round
patch.mpfr_add and
mpfr_sub functions call this code, depending on the signs
of the inputs). It can possibly yield undefined behavior, as the result
may not be normalized (if MPFR had been built with
the --enable-assert configure option, an assertion failure
occurs in such a case). This bug cannot occur if the input and output
precisions of the subtraction are the same, but it can also be triggered
by functions that call mpfr_add or mpfr_sub
with different precisions, e.g. by mpfr_fma
and mpfr_fms. All the MPFR versions
up to version 3.0.0 are affected. This bug is fixed by the
mpfr_sub1 patch (which also
provides testcases for mpfr_sub and mpfr_fma).
This patch has been
backported
for older MPFR versions.mpfr_sub1
bug report on the tracker]mpfr_set_ld function is buggy on very small
values. This bug cannot occur on platforms where the long double
type corresponds to x87 extended precision or less, but it has been observed
on a platform with quadruple precision. This bug is fixed by the
mpfr_set_ld patch.mpfr_set_ld
bug report on the tracker]do,
while or sizeof is still forbidden,
and other restrictions may be added in the future (unless
MPFR_USE_NO_MACRO has been defined).Bugs that are fixed in the trunk and in the 3.0 branch (for the future MPFR 3.0.1 version), with changesets for the 3.0 branch:
_GMP_IEEE_FLOATS defined (e.g. because the --with-gmp-build configure option was used), the generated code may be wrong for due to broken aliasing rules. Potentially affected functions: those that convert a MPFR number to a native floating-point number. No wrong code has actually been reported, but since some tests failed in the past for a similar bug, concerned users may want to apply the patch given by the changeset below.mpfr_jn (thus for mpfr_j0 and mpfr_j1 too), the exponent range is not widened and the global flags are not saved, meaning that results can be wrong if the current exponent range is too small and some flags may incorrectly be set.mpfr_li2 crashes or has other undefined behavior (due to missing argument for fprintf).mpfr_sum test tsum.c does not handle null values correctly. In particular, one gets an assertion failure in mpfr_get_str when running the test with MPFR_LOG_ALL=1 (when logging is enabled).mpfr_subnormalize function does not set the inexact and underflow flags when needed (the behavior was unspecified for the underflow flag, but it was clearly a bug for the inexact flag, to be consistent with the returned ternary value). The changeset below also has an update for the MPFR manual.mpfr_get_sj can have the following problem. If the resulting integer is a non-zero value that is small enough in absolute value, then the function can perform a right shift with a shift count larger than or equal to the width of the left operand; this has an undefined behavior. However such a shifted value is always 0 here, so that most current platforms (if not all) should be unaffected by this problem (except if compiler features to dynamically detect undefined behavior are used).mpfr_jn: for negative n, incorrect error analysis; for n = 0, integer overflow when determining the initial working precision. In mpfr_gamma: for small arguments whose absolute value is a power of two, the result may not be correctly rounded in the MPFR_RNDA rounding mode and/or if the argument is negative (in rounding to nearest, only the ternary value can be incorrect). Other various bugs:
mpfr_acos, mpfr_agm, mpfr_atan2, mpfr_div_2si, mpfr_div_2ui, mpfr_j0, mpfr_j1, mpfr_jn, mpfr_mul_2si, mpfr_y0, mpfr_y1, mpfr_yn, mpfr_zeta) do not behave correctly in extremely reduced exponent range; this was described in the BUGS file.mpfr_agm, mpfr_div_2si, mpfr_div_2ui, mpfr_fmod, mpfr_j0, mpfr_j1, mpfr_jn, mpfr_mul_2si, mpfr_remainder, mpfr_remquo) can have intermediate exceptions, provide incorrect flags, and/or have incorrect error analysis on some special values (such as huge or tiny); this was more or less described in the BUGS file.mpfr_erfc wrongly underflows for x ≥ 27282.mpfr_erfc can incorrectly set flags or possibly crash.mpfr_pow function behaves incorrectly on reused arguments (mpfr_pow(x,x,y,rnd) or mpfr_pow(y,x,y,rnd) for instance): when x is negative and |y| is an odd integer larger than 2256, the returned result can have a wrong sign (positive instead of negative) and possibly be rounded in the wrong direction.Other bugs: please see the tracker and the BUGS file.
Note: if you are trying to build GCC and get the error header files gmp-impl.h and longlong.h not found
, please look at GCC bug 44455. This problem is a consequence of a correction in the detection of a GMP build directory.
mpfr_random
and mpfr_random2 have been removed, the meaning of the return
type of the function mpfr_get_f has changed, and the return type
of the function mpfr_get_z is now int instead of
void. In practice, this should not break any existing code.MPFR_RNDA) is available to round away
from zero.mpfr_rnd_t (as in previous
versions, both mpfr_rnd_t and mp_rnd_t are
accepted, but mp_rnd_t may be removed in the future).mpfr_prec_t (as in previous
versions, both mpfr_prec_t and mp_prec_t are
accepted, but mp_prec_t may be removed in the future) and
it is now signed (it was unsigned in MPFR 2.*, but
this was not documented). In practice, this change should not affect
existing code that assumed nothing on the precision type.mpfr_exp_t, which is currently the same as
GMP's mp_exp_t.mpfr_random and mpfr_random2
have been removed.mpfr_get_f and mpfr_get_z now return a
ternary value.mpfr_strtofr now accepts bases from 37 to 62.mpfr_custom_get_mantissa was renamed to
mpfr_custom_get_significand
(mpfr_custom_get_mantissa is still available
via a #define).mpfr_get_si, mpfr_get_ui,
mpfr_get_sj, mpfr_get_uj, mpfr_get_z
and mpfr_get_z_2exp no longer have cases with undefined
behavior; in these cases, the behavior is now specified, and in
particular, the erange flag is set.mpfr_buildopt_tls_p and
mpfr_buildopt_decimal_p giving information
about options used at MPFR build time.mpfr_regular_p.mpfr_set_zero.mpfr_digamma.mpfr_ai (incomplete, experimental).mpfr_set_flt and mpfr_get_flt
to convert from/to the float type.mpfr_urandom.mpfr_set_z_2exp (companion to
mpfr_get_z_2exp, which was renamed from
mpfr_get_z_exp in previous versions).mpfr_min_prec.mpfr_sin, mpfr_cos, mpfr_tan,
mpfr_sin_cos): speedup of about 2.5 for 105 digits,
of about 5 for 106 digits.arcsin, arccos, arctan):
about 2 for 103 digits, up to 2.7 for 106 digits.long double formats (double big endian, double little endian,
double-double big endian).MPFR 3.0.0 has been successfully compiled and checked on the following platforms: