File _patchinfo of Package patchinfo.19111

<patchinfo incident="19111">
  <issue tracker="bnc" id="1141190">LTO: mpfr make check failure for ppc64le</issue>
  <packager>rguenther</packager>
  <rating>moderate</rating>
  <category>recommended</category>
  <summary>Recommended update for mpfr</summary>
  <description>This update for mpfr fixes the following issues:

- Fixed an issue when building for ppc64le (bsc#1141190)

Technical library fixes:

- A subtraction of two numbers of the same sign or addition of two numbers of different signs
  can be rounded incorrectly (and the ternary value can be incorrect) when one of the two
  inputs is reused as the output (destination) and all these MPFR numbers have exactly
  GMP_NUMB_BITS bits of precision (typically, 32 bits on 32-bit machines, 64 bits on 64-bit
  machines).
- The mpfr_fma and mpfr_fms functions can behave incorrectly in case of internal overflow or
  underflow.
- The result of the mpfr_sqr function can be rounded incorrectly in a rare case near underflow
  when the destination has exactly GMP_NUMB_BITS bits of precision (typically, 32 bits on
  32-bit machines, 64 bits on 64-bit machines) and the input has at most GMP_NUMB_BITS bits
  of precision.
- The behavior and documentation of the mpfr_get_str function are inconsistent concerning the
  minimum precision (this is related to the change of the minimum precision from 2 to 1 in
  MPFR 4.0.0). The get_str patch fixes this issue in the following way: the value 1 can now be
  provided for n (4th argument of mpfr_get_str); if n = 0, then the number of significant digits
  in the output string can now be 1, as already implied by the documentation (but the code was
  increasing it to 2).
- The mpfr_cmp_q function can behave incorrectly when the rational (mpq_t) number has a null
  denominator.
- The mpfr_inp_str and mpfr_out_str functions might behave incorrectly when the stream is a
  null pointer: the stream is replaced by stdin and stdout, respectively. This behavior is
  useless, not documented (thus incorrect in case a null pointer would have a special meaning),
  and not consistent with other input/output functions.
</description>
</patchinfo>