mpfr: Update to version 4.1.0 plus patches 1 to 13

mpfr: Update to version 4.1.0 plus patches 1 to 13

- Update from version 4.1.0 to 4.1.0 plus patches 1 to 13
- Version 4.1.0 was released on 10-07-2020. However patches have been progressively
   issued to fix various bugs that have been identified.
- Currently 13 patches have been issued and mpfr provide a cumulative patches file to
   use to patch the source file.
- Update of rootfile
- Patch changelog
   1 With GCC (the only tested compiler with software _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.
     Corresponding changeset in the 4.1 branch: 14094.
   2 The random_deviate.c file contains non-portable code. This is fixed by the
     random_deviate patch.
     Corresponding changeset in the 4.1 branch: 14126.
   3 In the 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 2^32 (as
     usual). However, UBsan would detect the overflow, and LTO might have unpredictable
     effects.
     Corresponding changesets in the 4.1 branch: 14147, 14151.
   4 Some function prototypes are slightly inconsistent. This is valid C code, but
     these inconsistencies are unintended and possibly confusing, and they trigger
     diagnostics with the -Warray-parameter option of the future GCC 11 (included in
     -Wall). This causes issues when testing MPFR. And since mpfr.h is concerned, this
     might also affect user code. This is fixed by the prototypes patch.
     Corresponding changeset in the 4.1 branch: 14411.
   5 In uncommon cases, the 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).
     Corresponding changeset in the 4.1 branch: 14424.
   6 The 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).
     Corresponding changeset in the 4.1 branch: 14425.
   7 The Bessel functions (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).
     Corresponding changeset in the 4.1 branch: 14426.
   8 The 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).
     Corresponding changeset in the 4.1 branch: 14435.
   9 The Bessel functions (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).
     Corresponding changeset in the 4.1 branch: 14436.
  10 Some functions are also implemented as macros, and such a macro should behave
     exactly like the corresponding function (if the code is valid for the function
     call). However, the following macros do not behave as if their argument were
     implicitly converted to the type from the function prototype: 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.
     Corresponding changesets in the 4.1 branch: 14468, 14469.
  11 The test programs tset_si and tset_sj fail if MPFR_USE_NO_MACRO is defined (e.g.,
     via -DMPFR_USE_NO_MACRO in CFLAGS). This is fixed by the tset_sij patch.
     Corresponding changeset in the 4.1 branch: 14470.
  12 The 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.
     Corresponding changeset in the 4.1 branch: 14490.
  13 The code for the formatted output functions (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.
     Corresponding changesets in the 4.1 branch: 14524, 14525.

Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>