Mention https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467

Note: INITIALIZED() is currently used only in "sub1sp.c".

This is necessary to avoid a maybe-uninitialized warning or error with
"-DMPFR_WANT_ASSERT" (= 1 or 2, e.g. via --enable-assert) and "-O2".

The test

  check_vsprintf ("+01,234,567  :", "%0+ -'13.10Pd:", (mpfr_prec_t) 1234567);

is based on the output from glibc up to 2.36, which is incorrect:

  https://sourceware.org/bugzilla/show_bug.cgi?id=23432

The GNU C Library has apparently been partially fixed in its Git
repository for the future 2.37, since a tsprintf failure has been
reported (this is a bug in this test, not in the MPFR library):

  https://sympa.inria.fr/sympa/arc/mpfr/2023-01/msg00001.html

So, modified the test to avoid the particular case of leading zeros
due to the precision field larger than the number of digits. This
case has already been tested without the thousands separator (where
there are no issues with the C libraries), so that we do not miss
much testing. Added a comment explaining the issue and a possible
solution for future testing of this particular case (if need be).

(cherry picked from commit 2172af93)

With GCC's -Werror=unused-function (used in testing), the build was
failing if none of HAVE_LDOUBLE_IEEE_EXT_* was defined. This could
be detected by providing mpfr_cv_c_long_double_format=unknown.

Note: My previous explanation was implicitly based on the fact that
tiny arguments s were already taken into account. But if the precision
is really huge (see the condition), this is not the case, so that the
MPFR_EMAX_MAX lower bound on the precision may have been incorrect.
Anyway, as noticed by Paul, one can use the fact that one would have
|s| less than the minimum representable positive number (i.e. without
needing the filtering of tiny arguments).

The current error analysis does not taken into account the use of
mpfr_sinpi (commit fd5d811d), which
could have reduced the error bound compared to the multiplication
by π and the use of mpfr_sin.

Before commit fd5d811d, there was
"Can mpfr_sin underflow?" in a FIXME. Indeed, we could not answer
without a theoretical study. This commit updated the FIXME to
"Can mpfr_sinpi underflow?". But now with mpfr_sinpi, an underflow
is no longer possible due to limitations on huge precisions; added
a full explanation in the comment.

To be similar to the other files, added:
* Contributed by the AriC and Caramba projects, INRIA.
* This file is part of the GNU MPFR Library.

(These Makefile.am files still have their special license.)

Command used:
  perl -pi -e 's/ (\d{4}-)?(2022)(?= Free Software)/
               " ".($1||"$2-").($2+1)/e' **/*(^/)
under zsh, reverting doc/texinfo.tex (copied from GNU Texinfo)
and the tools/mbench directory (not distributed with MPFR).
Removed 2022 from the example in the doc/README.dev file.

In short, this test had been added to detect a MPFR bug with
16-bit limbs, fixed a bit later. But a failure reappeared on
emulated m68k machines, due to a bug in QEMU caused by the
specific m68k extended-precision format.

First, the check_qemu_m68k_bug() code was valid only with 15-bit
long double exponents or more, thus not on every architecture.
Moreover, the MPFR tests are not there to detect bugs in the native
floating-point arithmetic. So this check is now done only when
bug20180904() fails (as this QEMU bug is now the probable cause of
this failure) in order to instruct the user that this is probably
not a MPFR bug.

TODO: Make the code C90 compatible.

This code was commented out in the previous commit. Let's remove it
completely because it was buggy for HAVE_LDOUBLE_IEEE_QUAD_*, as this
has been noticed by Joseph Myers:
  https://sympa.inria.fr/sympa/arc/mpfr/2022-12/msg00052.html

Moreover, the HAVE_LDOUBLE_IEEE_EXT_BIG interpretation is not decided
yet and could be used for m68k, with "e2 = -16446" instead of -16445.

The tget_ld_2exp failure was apparently due to a bug in QEMU, which
is not aware of the m68k extended-precision format. The MPFR code is
correct (the HAVE_LDOUBLE_IEEE_EXT_BIG macro is not used yet, and if
it is used in the future, we could decide that it corresponds to the
m68k extended-precision format, as the x86 extended-precision format
seen in practice is little endian, i.e. HAVE_LDOUBLE_IEEE_EXT_LITTLE
is set). There's now check_qemu_m68k_bug() about this QEMU bug.

* BUGS: removed the text added in commit 85a70806 since the MPFR
  generic code is used on m68k for conversions with long double
  (HAVE_LDOUBLE_IEEE_EXT_BIG is not used yet). The tget_ld_2exp
  failure was apparently due to a bug in QEMU, which is not aware
  of the m68k extended-precision format. See:
    https://sympa.inria.fr/sympa/arc/mpfr/2022-12/msg00036.html
    https://sympa.inria.fr/sympa/arc/mpfr/2022-12/msg00039.html
* acinclude.m4: updated comment for MPFR_C_REALFP_FORMAT(long double,L)
  with some text that was in BUGS. In short, it appears that
  HAVE_LDOUBLE_IEEE_EXT_LITTLE = x86 extended precision and
  HAVE_LDOUBLE_IEEE_EXT_BIG = m68k extended precision, where
  emin(m68k) = emin(x86) − 1.
* doc/README.dev: update.

(Stéphane Glondu checked it fails with -O0, -O1 and -O2 on "mitchy")

References:
  https://www.nxp.com/docs/en/reference-manual/M68000PM.pdf
  MPFR mailing-list.

C90 compatibility; more robust.

(see https://sympa.inria.fr/sympa/arc/mpfr/2022-12/msg00032.html)

* No longer exclude '^tests/tabort_defalloc': this is no longer needed
  since commit 41bed903 in 2017.
* Exclude a new comment.

Added info about the status under OpenBSD 7+.

This reverts commit b5f229d1.

The test of the %n printf specifier with the mpfr_*printf functions
is actually not an issue since we handle %n in vasprintf.c (so the
OpenBSD C library will never see it). That's why with a GMP compiled
under OpenBSD 6.9 (thus with HAVE_VSNPRINTF defined), the MPFR tests
still succeed after an upgrade of the machine to OpenBSD 7.2.

This issue started to appear with OpenBSD 7+ too, which no longer
supports the standard %n printf specifier. This is detected by
GMP's configure, so that HAVE_VSNPRINTF is not defined. If GMP is
built with HAVE_VSNPRINTF manually defined, this would would make
the failure with %a/%A disappear, but would trigger failures due to
the %n test in several MPFR tests.

In short, if the error is like
  repl-vsnprintf.c:389: GNU MP assertion failed: len < total_width
this is a GMP (or MPIR) issue in __gmp_replacement_vsnprintf.

References:
  https://sympa.inria.fr/sympa/arc/mpfr/2022-10/msg00001.html
  https://sympa.inria.fr/sympa/arc/mpfr/2022-10/msg00027.html
  https://gmplib.org/list-archives/gmp-bugs/2022-October/005200.html

Due to commit 4885b57a, only the first
of the 4 replacements in INSTALL was done.

* doc/mpfr.texi: mentioned C++ compilers and the potential issue
  with type punning via union.
* INSTALL: completed (0) to be similar to what doc/mpfr.texi says.

The reason is that on some platforms, GMP chooses a non-default mode
(a.k.a. ABI). MPFR has some workaround thanks to GMP_CC and GMP_CFLAGS
provided by GMP, but this may not be sufficient, e.g. on power-aix. In
such a case, the user needs to either force GMP to use the default mode
or provide an AR variable for MPFR's configure; see INSTALL file.

(cherry picked from commit 89f4f4d2)