- 19 Jan, 2023 1 commit
-
-
Vincent Lefevre authored
Mention https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467
-
- 17 Jan, 2023 2 commits
-
-
Vincent Lefevre authored
Note: INITIALIZED() is currently used only in "sub1sp.c".
-
Vincent Lefevre authored
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".
-
- 15 Jan, 2023 1 commit
-
-
Vincent Lefevre authored
-
- 10 Jan, 2023 1 commit
-
-
Vincent Lefevre authored
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).
-
- 06 Jan, 2023 2 commits
-
-
Vincent Lefevre authored
(cherry picked from commit 2172af93)
-
Vincent Lefevre authored
-
- 05 Jan, 2023 8 commits
-
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
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).
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
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.)
-
Vincent Lefevre authored
-
Vincent Lefevre authored
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.
-
ZIMMERMANN Paul authored
-
- 04 Jan, 2023 1 commit
-
-
Vincent Lefevre authored
-
- 22 Dec, 2022 1 commit
-
-
Vincent Lefevre authored
-
- 21 Dec, 2022 6 commits
-
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
* 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.
-
ZIMMERMANN Paul authored
(Stéphane Glondu checked it fails with -O0, -O1 and -O2 on "mitchy")
-
- 20 Dec, 2022 4 commits
-
-
Vincent Lefevre authored
References: https://www.nxp.com/docs/en/reference-manual/M68000PM.pdf MPFR mailing-list.
-
Vincent Lefevre authored
-
Vincent Lefevre authored
C90 compatibility; more robust.
-
-
- 17 Dec, 2022 1 commit
-
-
Vincent Lefevre authored
* No longer exclude '^tests/tabort_defalloc': this is no longer needed since commit 41bed903 in 2017. * Exclude a new comment.
-
- 16 Dec, 2022 3 commits
-
-
Vincent Lefevre authored
Added info about the status under OpenBSD 7+.
-
Vincent Lefevre authored
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.
-
Vincent Lefevre authored
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.
-
- 15 Dec, 2022 4 commits
-
-
Vincent Lefevre authored
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
-
Vincent Lefevre authored
-
Vincent Lefevre authored
Due to commit 4885b57a, only the first of the 4 replacements in INSTALL was done.
-
Vincent Lefevre authored
* 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.
-
- 14 Dec, 2022 1 commit
-
-
Vincent Lefevre authored
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.
-
- 13 Dec, 2022 4 commits
-
-
Vincent Lefevre authored
-
Vincent Lefevre authored
(cherry picked from commit 89f4f4d2)
-
Vincent Lefevre authored
-
Vincent Lefevre authored
-