`mpfr_*printf`

):
Patch 12: Possible undefined behavior in case of error: store to null pointer, free of bad pointer, and

`<stdarg.h>`related undefined behavior.Patch 13: The flags for the

`P`length modifier (`mpfr_prec_t`argument) are ignored; this includes the sign of the field width when the value is provided in argument (by using an asterisk`*`in the format string).

The main issue is that the `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 is fixed by patch 11.

The main issue can occur with the formatted output functions (`mpfr_*printf`

) when the `'` flag is used in a locale where the thousands separator is not empty. 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 free

function 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.

For the users of the `Math::MPFR` Perl module, note that patch 6 makes a bug appear in version 4.03 of this module (current version at the time of writing – **[Update 2018-05-08]** A new version of the module is now available).

`mpfr_div_ui`

function, which was present since the introduction of `mpfr_div_ui`

at the very beginning of the development of MPFR in 1999. But as of version 4.0.0, this bug was also affecting the `mpfr_div`

function.
These versions 4.0.* contain many changes compared to versions 3.1.* (GNU MPFR 3.1.0 had been released in October 2011).

]]>By the way, I did my first MPFR commit 17 years ago.

]]>`mpfr_get_ld`

, `mpfr_get_si`

, `mpfr_get_ui`

, `mpfr_get_sj`

, `mpfr_get_uj`

and `mpfr_get_z`

when called with a very reduced exponent range.
]]>Improved MPFR manual.

Bug fixes (detailed list on the MPFR 3.1.5 page and

`ChangeLog`file).Autotools: Under Linux, make sure that the old dtags (when supported) are used if the

`LD_LIBRARY_PATH`environment variable is defined; otherwise

would check an installed, compatible MPFR library found in`make check``LD_LIBRARY_PATH`instead of the one that has been built with

.`make`

`mpfr_sin`

, `mpfr_cos`

, `mpfr_tan`

) and functions that call them can be very inaccurate (limiting the overall accuracy to about one million bits for these functions on such platforms).
]]>Correctly Rounded Arbitrary-Precision Floating-Point Summation, to be published in IEEE Transactions on Computers. DOI: 10.1109/TC.2017.2690632 (official link). PDF file on my personal web site (freely downloadable, © IEEE). Abstract:

We present a fast algorithm together with its low-level implementation of correctly rounded arbitrary-precision floating-point summation. The arithmetic is the one used by the GNU MPFR library: radix 2; no subnormals; each variable (each input and the output) has its own precision. We also give a worst-case complexity of this algorithm and describe how the implementation is tested.

Optimized Binary64 and Binary128 Arithmetic with GNU MPFR, written with Paul Zimmermann. Accepted at the 24th IEEE Symposium on Computer Arithmetic (ARITH 24), which will take place on 24–26 July 2017 in London, England. Abstract:

We describe algorithms used to optimize the GNU MPFR library when the operands fit into one or two words. On modern processors, a correctly rounded addition of two quadruple precision numbers is now performed in 22 cycles, a subtraction in 24 cycles, a multiplication in 32 cycles, a division in 64 cycles, and a square root in 69 cycles. We also introduce a new

*faithful*rounding mode, which enables even faster computations. Those optimizations will be available in version 4 of MPFR.

The

`tzeta`test should no longer fail on most platforms (IEEE 754 machines with default IEEE exception handling).The

`tsprintf`test still fails (fix in progress). The cause is a major efficiency issue in particular cases (huge precision requested).

Note: Both problems are also present in the released versions, but they have no tests that trigger them.

]]>`mpfr_strtofr`

function can return an incorrect ternary value in the round-to-nearest mode (`MPFR_RNDN`

).
]]>