2025-03-20  Vincent Lefevre  <vincent@vinc17.net>

	Updated version to 4.2.2.

2025-03-14  Vincent Lefevre  <vincent@vinc17.net>

	Corrected documentation about the failing check_null() tests (bug in GMP)

	following commit e545a46332bc41f15eab7de7e19c851f311762ff.

	This is not specific to Visual C++ under MS Windows, but due to a bug
	in GMP's vsnprintf replacement (now fixed in its development branch).

	* INSTALL: moved and updated text about failures in the testsuite.
	  New section: "tfprintf and tsprintf failures in check_null".
	* doc/README.dev: updated MPFR_TESTS_SKIP_CHECK_NULL description.

2025-03-14  Vincent Lefevre  <vincent@vinc17.net>

	ChangeLog update with tools/update-changelog

	Updated version to 4.2.2-rc1.

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	[NEWS] Update for 4.2.2 (mention 2 bug fixes)

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	Added MPFR_TESTS_SKIP_CHECK_NULL: optionally skip the check_null() tests.

	Build the MPFR tests with the MPFR_TESTS_SKIP_CHECK_NULL macro defined
	in order to skip the check_null() tests in tfprintf.c and tsprintf.c
	(failures with Visual C++ under MS Windows have been reported). The
	goal is just to avoid a failure of the MPFR testsuite, as the bug seems
	to come from neither MPFR nor GMP.

	* INSTALL: mention the failures with Microsoft Visual C++ and how
	  to skip the corresponding tests.
	* doc/README.dev: document MPFR_TESTS_SKIP_CHECK_NULL.
	* tests/{tfprintf.c,tsprintf.c}: skip the check_null() tests if
	  the MPFR_TESTS_SKIP_CHECK_NULL macro is defined.

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	[INSTALL] Moved notes for the CompCert and Intel OneApi compilers.

	They were added under the "MPFR for use with Windows Applications"
	section[*], but they actually concerned Linux.

	[*] commit 5075ec08449b4d59aba7700a127bc7f35718cc3f (SVN r13849)
	    commit 5543355cd613d1cfdd428b87101b0606648a50fa (SVN r14552)

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	[NEWS] Update for 4.2.2

	Added "Changes from version 4.2.1 to version 4.2.2" and moved an item
	there (from commit a8cc66a9cc960545514470e41d5bbfaa64d89743).

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	[src/mpfr-longlong.h] __int128__ → __int128 for portability (clang).

	This is an update from the current GMP development code
	(18482:d6c6436467ab in the GMP repository).

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tversion.c] Do not output gmp_*printf info when meaningless.

	In particular, mini-gmp does not provide gmp_*printf functions, thus
	it does not make any sense to output the corresponding lines.

	Until now, one was getting

	[tversion] gmp_printf: hhd = yes, lld = yes, jd = yes, td = ?, Lf = ?
	[tversion] gmp_snprintf/vsnprintf on "%a" = ?

	The "?" corresponded to the absence of the tests, thus could be
	regarded as correct. But the "yes" was just the default, thus was
	actually incorrect and misleading. Note that this default does not
	matter for mini-gmp since the formatted output functions are not
	tested: the corresponding test files have

	  #if defined(HAVE_STDARG) && !defined(MPFR_USE_MINI_GMP)

	and we are now using the same test.

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	Detect the use of GMP's buggy vsnprintf replacement at configure time.

	* acinclude.m4: detect the use of GMP's buggy vsnprintf replacement
	  at configure time. With it, the tests of "%a" will be disabled to
	  avoid an assertion failure in the MPFR testsuite. A warning will
	  be displayed in the configure output in such a case.
	* doc/mpfr.texi: corrected/improved the documentation of the
	  conversion specification not involving "P" and "R" types.
	* tests/tsprintf.c: disable the tests of "%a" if need be (see above).
	* tests/tversion.c: output information about gmp_snprintf/vsnprintf
	  support of "%a".
	* NEWS: added an item about this.

2025-03-12  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tversion.c] Typo in output.

	For NPRINTF_L / PRINTF_L (see acinclude.m4), it should be "Lf",
	not "Ld" (f: floating-point type; d: signed integer type).

2025-03-07  Vincent Lefevre  <vincent@vinc17.net>

	[acinclude.m4] Clean up support for binary128 (correction).

	commit c37c9d599b9aced92e182507bf223440bbc9a9f1 was incomplete.

	We also need to get rid of the "#define _Float128 __float128" in
	the configure test (but this one does not affect Clang).

2025-03-06  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Updated the month.

2025-03-06  Vincent Lefevre  <vincent@vinc17.net>

	Portability: clean up support for binary128 (a.k.a. float128).

	This fixes a configure failure with Clang and glibc 2.41:
	  https://bugs.gentoo.org/949962
	  https://sourceware.org/bugzilla/show_bug.cgi?id=32750
	  https://sympa.inria.fr/sympa/arc/mpfr/2025-02/msg00025.html
	  https://sympa.inria.fr/sympa/arc/mpfr/2025-03/msg00001.html

	The issue is the following: in its configure script, GNU MPFR first
	tests whether _Float128 is supported (without header inclusions);
	if it isn't, MPFR then tests whether __float128 is supported, and
	in such a case, it defines _Float128 as __float128 with

	  AC_DEFINE([_Float128],[__float128],[__float128 fallback])

	As Clang supports __float128 but not _Float128 (at least on x86_64,
	up to version 19), this fallback is selected. But glibc 2.41 has a
	similar fallback, with a typedef:

	  typedef __float128 _Float128;

	With the MPFR _Float128 macro defined as __float128, as soon as some
	header such as <stdio.h> is included, this yields

	  typedef __float128 __float128;

	which is incorrect. This first occurs in the

	  AC_MSG_CHECKING(for GMP_NUMB_BITS and sizeof(mp_limb_t) consistency)
	  [...]

	configure test (in configure.ac), hence the failure of this test and
	the configure script.

	As an attempt to avoid such an issue with header inclusion, a solution
	should be to include the common headers in every configure test.

	But since _Float128 is a reserved identifier, we must avoid defining
	it as a macro (a typedef would also be incorrect). This is done here,
	by defining a mpfr_float128 macro instead. In the public mpfr.h header
	file, if the user has defined MPFR_WANT_FLOAT128: mpfr_float128 will
	be defined as _Float128 by default (thus this will not change the API),
	but if _Float128 is not supported, the user should define mpfr_float128
	as __float128 (or an equivalent type that is supported).

	* acinclude.m4: changed _Float128 to mpfr_float128 in AC_DEFINE.
	* configure.ac: updated a comment about _Float128.
	* doc/README.dev: update about MPFR_WANT_FLOAT128 and _Float128.
	* doc/mpfr.texi: in "Nomenclature and Types", added a paragraph about
	  binary128 support and the mpfr_float128 macro; update concerning the
	  functions related to binary128 (in particular, in the prototypes,
	  changed _Float128 to mpfr_float128).
	* src/mpfr.h: under "#ifdef MPFR_WANT_FLOAT128", define mpfr_float128
	  as _Float128 if not defined yet; in the prototypes, changed
	  _Float128 to mpfr_float128.
	* src/get_float128.c, src/set_float128.c, tests/tset_float128.c:
	  changed _Float128 to mpfr_float128; updated comments.
	* tests/tversion.c: for "float128 = yes", also output the actual type.

2025-02-13  Vincent Lefevre  <vincent@vinc17.net>

	[MPFR manual] Added a paragraph for formatted output functions and a/A.

	Reference and discussion about the choice of the exponent:
	  https://sympa.inria.fr/sympa/arc/mpfr/2021-05/msg00002.html

2025-02-12  Vincent Lefevre  <vincent@vinc17.net>

	[MPFR manual] mpfr_subnormalize: corrected subnormal exponent range.

	For mpfr_subnormalize, the subnormal exponent range is
	[emin,emin+PREC(x)-2], not [emin,emin+PREC(x)-1].

	Indeed, in precision p, there are p-1 exponents in the subnormal domain
	(the subnormal numbers are represented with 1 to p-1 significant bits).

	Note: the range got corrected in a src/subnormal.c comment on 2011-01-27
	(SVN r7437, commit 49086d17298227973015e3c6fa97d95ea533cd43), but the
	old range remained in doc/mpfr.texi, where it was added on 2005-04-14
	(SVN r3442, commit 1ba17a49315bb425028e8613b89fa7c48d6b2c53).

2025-02-01  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Mention the Pascaline project-team.

	[tools/check_mparam.c] Updated the "Contributed" line.

2025-02-01  Vincent Lefevre  <vincent@vinc17.net>

	Updated the "Contributed" lines.

	Replaced
	  Contributed by the AriC and Caramba projects
	by
	  Contributed by the Pascaline and Caramba projects
	in every file (except ChangeLog).

2025-02-01  Vincent Lefevre  <vincent@vinc17.net>

	[src/set_d128.c] Replaced "Caramel" by "Caramba".

	This file was added with an incorrect "Contributed" line in SVN r12766
	(commit 39cfc1ede643df1288f3d6fce2eafa408161f2c1).

	Note: there is a bug in git, which thinks that this file comes from
	src/set_d64.c, thus lists the change from "Caramel" to "Caramba" in
	its history, which is wrong!

2025-01-02  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Updated the month.

2025-01-02  Vincent Lefevre  <vincent@vinc17.net>

	Copyright notice update: added 2025.

	Command used:
	  perl -pi -e 's/ (\d{4}-)?(2024)(?= Free Software)/
	               " ".($1||"$2-").($2+1)/e' **/*(^/)
	under zsh (note: doc/texinfo.tex, from GNU Texinfo, isn't modified).
	Removed 2024 from the example in the doc/README.dev file.

2024-12-10  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Updated the month.

2024-12-10  Vincent Lefevre  <vincent@vinc17.net>

	MPFR manual: replaced variable "bool" by "cond" in examples.

	As bool is a keyword in ISO C23, we should not use it as a variable name
	(even in examples).

2024-12-10  Vincent Lefevre  <vincent@vinc17.net>

	[doc/README.dev] Update from the master branch, except new features.

	Documentation of features present in master but not in the 4.2 branch
	has been removed.

2024-09-09  Vincent Lefevre  <vincent@vinc17.net>

	[src/get_str.c] Renamed a variable.

	Renamed variable "reste" (French) to "rem".
	"reste" was triggering a error with codespell 2.3.0.

2024-09-05  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Updated the month.

2024-09-04  Vincent Lefevre  <vincent@vinc17.net>

	[doc] Update to GNU Free Documentation License 1.3

	In practice, this doesn't change anything for MPFR users, but
	the FSF address in FDL 1.2 became obsolete, and this also fixes
	a bug ("GNU Free Documentation License" was appearing twice in
	the Concept Index).

	See other details at
	  https://sympa.inria.fr/sympa/arc/mpfr/2024-09/msg00001.html

	At the same time, 2 old tweaks from GMP (added in 2002) have been
	removed:
	  * one to help texinfo-mode (which should have now been fixed);
	  * one that was using @appendixsec for the addendum (adding "A.1"
	    before the addendum title and possibly an item in the table of
	    contents, but this is not really needed and this is strange for
	    HTML output).

2024-09-04  Vincent Lefevre  <vincent@vinc17.net>

	[tools/mbench/Makefile] Updated copyright notice (FSF address changed).

	The postal address of the FSF has changed. Updated the copyright notice
	as in commit 9f2e53ef36ac196348ffafcc45ce8e5cc03fe007.

2024-09-04  Vincent Lefevre  <vincent@vinc17.net>

	[tests/data/*] Updated copyright notice (FSF address changed).

	Some of the files under tests/data contained a very old FSF address.
	No longer use the postal address. Updated the copyright notice as in
	commit 9f2e53ef36ac196348ffafcc45ce8e5cc03fe007.

	File gonnet.mpl updated manually, and other files with

	  perl -p0i -e 'BEGIN { $s =
	    "if not, write to the Free Software\n# Foundation, Inc.,".
	    " 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA."
	    } s#\Q$s\E#if not, see <https://www.gnu.org/licenses/>.#g'

2024-09-04  Vincent Lefevre  <vincent@vinc17.net>

	[tests/data/*] Updated copyright notice (FSF address changed).

	The postal address of the FSF has changed. Updated the copyright notice
	as in commit 9f2e53ef36ac196348ffafcc45ce8e5cc03fe007.

2024-09-04  Vincent Lefevre  <vincent@vinc17.net>

	[acinclude.m4] Updated copyright notice (FSF address changed).

	The postal address of the FSF has changed. Updated the copyright notice
	as in commit 9f2e53ef36ac196348ffafcc45ce8e5cc03fe007.

	Moreover, make the copyright notice fit on 80 columns.

2024-09-04  Vincent Lefevre  <vincent@vinc17.net>

	Updated copyright notice of almost all files (FSF address changed).

	This commit in the 4.2 branch is similar to the one in master
	(9f2e53ef36ac196348ffafcc45ce8e5cc03fe007).

	The postal address of the FSF has changed. Instead of updating it,
	use the recommendation from
	  https://www.gnu.org/licenses/gpl-howto.en.html
	for the copyright notice, i.e. no longer use the postal address;
	just give the web page <https://www.gnu.org/licenses/>.

	This commit updates the copyright notice of almost all files (the
	remaining files will be updated later). It has been obtained with

	  perl -p0i -e 'BEGIN { $s =
	      "If not, see\nhttps://www.gnu.org/licenses/ or write".
	      " to the Free Software Foundation, Inc.,\n51 Franklin St,".
	      " Fifth Floor, Boston, MA 02110-1301, USA." }
	      s# +\Q$s\E#\nIf not, see <https://www.gnu.org/licenses/>.#g' \
	    $(git ls-files)

2024-08-23  Vincent Lefevre  <vincent@vinc17.net>

	[src/logging.c] Replaced the obsolescent ctime() by strftime().

	We use the "%Y-%m-%d %H:%M:%S" time format (human-readable ISO 8601),
	which is easier to read than the ctime/asctime format.

2024-08-23  Vincent Lefevre  <vincent@vinc17.net>

	[src/logging.c] Added FIXME for ctime(), deprecated in POSIX & ISO C23.

	See https://www.open-std.org/JTC1/SC22/WG14/www/docs/n2566.pdf
	for details.

2024-02-15  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Updated the month.

2024-02-15  Vincent Lefevre  <vincent@vinc17.net>

	Copyright notice update: added 2024.

	Command used:
	  perl -pi -e 's/ (\d{4}-)?(2023)(?= Free Software)/
	               " ".($1||"$2-").($2+1)/e' **/*(^/)
	under zsh.
	Removed 2023 from the example in the doc/README.dev file.

2023-12-15  Vincent Lefevre  <vincent@vinc17.net>

	MPFR manual: added a note for mpfr_free_str.

	[doc/mpfr.texi] Updated the month.

2023-12-15  Vincent Lefevre  <vincent@vinc17.net>

	MPFR manual: corrections for formatted output functions (mpfr_*printf).

	Needed due to the possible use of %c with the value 0, thus with
	potential (non-terminating) null characters in the output.

	* Replaced "string" by "array" (term used in the ISO C standard).
	* Document requirements concerning the use of mpfr_free_str to free
	  the block of memory allocated by mpfr_asprintf / mpfr_vasprintf.

2023-12-13  Vincent Lefevre  <vincent@vinc17.net>

	Fixed bugs in the formatted output functions triggered with %c on 0.

	Possible consequences of these bugs:
	  - possible memory corruption with custom memory allocators that
	    do not ignore the size parameter of the "free" function;
	  - a part of the buffer fails to be overwritten;
	  - an assertion failure when GNU MPFR has been configured with
	    assertion checking (--enable-assert).

	* src/vasprintf.c: No longer use the strncpy, strncat and strlen
	  functions (thus mpfr_free_str as well), as they are incorrect
	  when the buffer contains a non-terminating null character, which
	  is possible when %c is used with the value 0. Instead, use memcpy
	  and mpfr_free_func; and removed 2 MPFR_ASSERTD occurrences that
	  were using strlen.
	* src/printf.c: No longer use *printf (with %s) and mpfr_free_str
	  functions, for the same reason. Instead, use fwrite, memcpy and
	  mpfr_free_func.
	* tests/tfprintf.c, tests/tsprintf.c: added a check_null test to
	  check mpfr_vfprintf and mpfr_sprintf with %c on 0.

2023-10-20  Vincent Lefevre  <vincent@vinc17.net>

	English language correction.

	Issue detected by codespell 2.2.6. Indeed, according to
	  https://www.merriam-webster.com/dictionary/determinate
	"determinate" is only an adjective, not a verb. 1913 Webster says
	that as a verb, it is obsolete.

2023-10-20  Vincent Lefevre  <vincent@vinc17.net>

	mpfrlint: for codespell, ignore URLs.

	This currently avoids a false positive "debbugs" with codespell 2.2.6.

2023-08-31  Vincent Lefevre  <vincent@vinc17.net>

	[src/sub1sp1_extracted.c] Fixed #include lines.

	However, this doesn't change anything in practice since this code
	is not used yet (see sub1sp.c and its "#if 0 && ...").

2023-08-31  Vincent Lefevre  <vincent@vinc17.net>

	[src] Added missing "#define int32_t int" for --enable-formally-proven-code

	Bug detected on FreeBSD/RISC-V, reported by Dennis Clarke.

	We didn't detect it under Linux because the GNU C Library defines
	these types when <stdlib.h> is included:

	  #if defined __USE_MISC || defined __USE_XOPEN_EXTENDED
	  # include <sys/types.h> /* we need int32_t... */

	Note: the code shouldn't use these standard types with #define, though
	this is probably safe as we don't use standard functions/macros here.

2023-08-22  Vincent Lefevre  <vincent@vinc17.net>

	[src/Makefile.am] Updated -version-info to 8:2:2 for MPFR 4.2.2.

	Updated version to 4.2.2-dev (with tools/update-version).

	ChangeLog update with tools/update-changelog

	Updated version to 4.2.1.

2023-08-18  Vincent Lefevre  <vincent@vinc17.net>

	ChangeLog update with tools/update-changelog

	[tools/gitlog-to-changelog] Improve --strip-cherry-pick for this repository.

	Updated version to 4.2.1-rc1.

2023-08-18  Vincent Lefevre  <vincent@vinc17.net>

	[configure.ac] More checks for the support of old dtags.

	There is an attempt to use the old dtags when LD_LIBRARY_PATH is
	defined in order to avoid issues with the testsuite when this path
	contains some compatible version of the MPFR library. However, the
	old dtags do not work everywhere at run time, even when they appear
	to work at link time (via -Wl,--disable-new-dtags).

	So, let's restrict to *-*-linux-gnu hosts. Unfortunately, this is
	not sufficient for Android/Termux, where config.guess currently
	identifies the host as GNU/Linux (matching *-*-linux-gnu) instead of
	Android, but the old dtags do not work at run time. So, let's also
	exclude Termux explicitly (a test to exclude all Android hosts would
	be better, though).

	Note: in most cases, LD_LIBRARY_PATH is not set, so that there should
	be no issues in practice.

2023-08-18  Vincent Lefevre  <vincent@vinc17.net>

	[NEWS] Update for 4.2.1

2023-08-18  Vincent Lefevre  <vincent@vinc17.net>

	[src/compound.c] Removed obsolete FIXME.

	The implementation changed in 63cc8dfaf4dd93d68bb4f12c0787046f8a525893
	(cherry picked in 952fb0f5cc2df1fffde3eb54c462fdae5f123ea6).

2023-08-17  Vincent Lefevre  <vincent@vinc17.net>

	[strtofr.c] Fixed 2 mpfr_strtofr bugs in case of huge negative exponent.

	This fixes the bugs triggered by bug20230606, mentioned at
	  https://sympa.inria.fr/sympa/arc/mpfr/2023-06/msg00000.html
	  https://sympa.inria.fr/sympa/arc/mpfr/2023-06/msg00001.html

	These bugs are integer overflows, meaning undefined behavior.
	In practice, the consequences may be incorrect results. But
	for the first bug, it has been seen that a GCC optimization
	makes the bug invisible.

	Note: There are other issues with the code for huge exponents
	(in strtofr.c and the MPFR_SADD_OVERFLOW macro from mpfr-impl.h).
	See FIXME from commits
	  aa30bfe3c868640852fa2510b0f228170e39c0c5
	  e06a073c157fe95dd24d16d9fc3eef3781b58795
	in master. But it is not clear whether the problematic cases can
	occur in the context of mpfr_strtofr: my attempts to trigger a
	problematic case failed, so that there is a chance that the code
	is actually correct; but many parameters are involved, including
	those based on the internal structure in limbs, so that it is
	difficult to say for now. A closer analysis needs to be done.
	Even if correct, the code would need to be cleaned up, proved,
	and better documented.

2023-08-17  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tstrtofr.c] Added testcases for mpfr_strtofr integer overflows.

	These bugs occur on inputs with a large negative exponents, such as
	"0.1E-99999999999999999999".

	A first bug was reported by Michael Jones at
	  https://sympa.inria.fr/sympa/arc/mpfr/2023-06/msg00000.html

	Second bug mentioned at
	  https://sympa.inria.fr/sympa/arc/mpfr/2023-06/msg00001.html

2023-08-16  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Updated the month.

2023-08-15  Vincent Lefevre  <vincent@vinc17.net>

	Formatted output functions: fixed ‘+’/space flags on NaN and Inf.

	This is about the documentation and behavior of the mpfr_printf,
	etc. functions on MPFR numbers (mpfr_t) only, i.e. with the ‘R’
	type specifier.

	The ‘+’ and space flags were ignored on NaN and Inf. While this
	was loosely documented as such (without an explicit mention of
	these flags), the GNU MPFR manual also says that the flags have
	the same meaning as for the standard ‘printf’ function. So this
	was contradictory and regarded as a bug.

	Behaving like the ISO C standard should give less surprise, and
	this is probably what is expected (better for alignment purpose).

	This was partly discussed at
	  https://sympa.inria.fr/sympa/arc/mpfr/2023-03/msg00003.html
	(only for NaN and the ‘+’ flag at that time).

	* doc/mpfr.texi: corrected the documentation.
	* src/vasprintf.c: fixed (the code is now simpler since the rule
	  is the same in all cases: real and non-real values).
	* tests/tsprintf.c: grouped all the tests of NaN and Inf, and
	  added much more tests (by constructing the format string in
	  nested loops instead of just a few hardcoded cases).

2023-08-15  Vincent Lefevre  <vincent@vinc17.net>

	[src/vasprintf.c] Coding style.

2023-08-10  Vincent Lefevre  <vincent@vinc17.net>

	[configure.ac] For libgmp, replaced AC_CHECK_LIB by our own link test.

	The issue with AC_CHECK_LIB is that it cannot know the prototype of
	mpz_init. Thus it declares the function without a prototype, which
	is obsolescent in ISO C, so that the compiler may complain (e.g.
	with GCC's -Werror=strict-prototypes option, which may be useful to
	detect bugs in MPFR). Moreover, the call is done with an incorrect
	prototype, which could also be an issue on some systems (currently,
	no prototype check is done when linking, but this might change in
	the future).

	Note also that this new test is more robust, in case GMP changes the
	symbol name in the future (the API does not need to be changed).

	For the reference:
	  https://sympa.inria.fr/sympa/arc/mpfr/2023-08/msg00003.html

2023-08-10  Vincent Lefevre  <vincent@vinc17.net>

	[configure.ac] Do the MPFR_CHECK_MP_LIMB_T_VS_* tests without -lgmp.

	Moved the two tests

	  MPFR_CHECK_MP_LIMB_T_VS_LONG
	  MPFR_CHECK_MP_LIMB_T_VS_INTMAX

	before the LIBS="-lgmp $LIBS" as linking with GMP is not needed for
	these tests (only mp_limb_t is used from gmp.h), and it is actually
	better not to link with GMP. Indeed, as said for these tests, which
	use AC_LINK_IFELSE:

	  AC_LINK_IFELSE is safer than AC_COMPILE_IFELSE, as it will detect
	  undefined function-like macros (which otherwise may be regarded
	  as valid function calls with AC_COMPILE_IFELSE since prototypes
	  are not required by the C standard).

	So linking with GMP could make a failure disappear in case of a bug
	somewhere, so that the bug could remain undetected.

2023-08-10  Vincent Lefevre  <vincent@vinc17.net>

	[acinclude.m4] Replaced <gmp.h> by "gmp.h" for #include.

	The tests from configure.ac all use #include "gmp.h", and for the
	MPFR build and tests, gmp.h is also included with #include "gmp.h"
	(by mpfr-impl.h). For consistency, do the same in acinclude.m4.

	Note: In practice, there should not be a difference, except if there
	is a gmp.h file somewhere in the MPFR build tree. But this is not
	supported, and this may break the build or the testsuite (whatever
	is used in the configure tests).

2023-07-19  Vincent Lefevre  <vincent@vinc17.net>

	[src/mpfr-gmp.h] Fix integer overflow when mp_limb_t < int (mini-gmp).

	When mp_limb_t is shorter than int (which is possible with mini-gmp),
	an integer promotion in udiv_qr_3by2 triggers an integer overflow,
	detected by testing MPFR with

	  ./configure --with-mini-gmp=/path/to/mini-gmp CC=gcc-13 \
	  CFLAGS="-O2 -fsanitize=undefined -fno-sanitize-recover
	          -DMINI_GMP_LIMB_TYPE=short"

	(many tests fail).

	Note that this is not detected by GCC 12 and before, probably due to
	an optimization bug that hides the UBsan error.

	Moreover, mini-gmp currently has the same bug in gmp_udiv_qr_3by2,
	but also in gmp_udiv_qrnnd_preinv; it needs to be fixed too in order
	to avoid the failures in the MPFR tests.

2023-07-19  Vincent Lefevre  <vincent@vinc17.net>

	[tests/trint.c] C2x compat: replaced function without a prototype.

	The second parameter of test_fct was "int (*g)()", i.e. a pointer to
	a function without a prototype, because 2 kinds of prototypes can be
	used:
	  * one with args (mpfr_ptr, mpfr_srcptr);
	  * one with args (mpfr_ptr, mpfr_srcptr, mpfr_rnd_t),
	    but only for mpfr_rint.
	This was not a problem thanks to the test "g == &mpfr_rint", i.e.
	we knew which one to use. However, as the Clang 16 warning message
	says for -Wdeprecated-non-prototype:
	"passing arguments to a function without a prototype is deprecated
	in all versions of C and is not supported in C2x".

	The best way to fix this is to use the prototype with 2 arguments
	(mpfr_ptr, mpfr_srcptr) for the parameter, as this is the general
	case. All we need to do is to cast &mpfr_rint to this prototype
	(this appears only twice).

	As these casts trigger the -Wcast-function-type warning when enabled,
	let's explicitly disable this warning for GCC and Clang in versions
	where it has been introduced.

2023-07-18  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tfpif.c] Removed "fclose (fh);" under "if (fh == NULL)".

	The fopen() failed, so fclose() is not needed, and this is even UB.

	Issue reported by Jerry James:
	  https://sympa.inria.fr/sympa/arc/mpfr/2023-07/msg00002.html
	as GNU libc recently added a "nonnull" function attribute:
	  https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=71d9e0fe766a3c22a730995b9d024960970670af

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	[doc/mpfr.texi] Updated the month.

	[src/inp_str.c] Resolved the FIXME on a deprecated use of ungetc.

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	Fixed mpfr_strtofr bug in parse_string when isspace(0) is true.

	When isspace(0) is true (allowed by ISO C for non-"C" locales), '\0'
	would be skipped if part of the leading whitespace. But it must be
	regarded as the terminating null character, from the definition of
	a string (before the notion of whitespace is involved). So let's
	stop explicitly on '\0'.

	Note: in such locales (Mutt's lib.h suggests that some systems are
	affected, but this was in 1998), this is a security vulnerability,
	because characters after the terminating null character are read to
	determine the result.

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	[inp_str.c] mpfr_inp_str: fixed the handling of '\0' in the word.

	When '\0' is not a whitespace character (which is almost always the
	case in practice), it was not handled correctly. For instance, if the
	word is the sequence { '1', '\0', '2' }, the string "1" was passed to
	mpfr_set_str because '\0' is regarded as a terminating null character,
	and one was getting a valid number while '\0' in a word is necessarily
	invalid. This is fixed by putting '*' at the beginning of the string,
	which is thus necessarily invalid.

	This fixes the failure after c9523bc6fb11c8eefc75524e947e5eb81e682675
	(4642e68fb3cd6793a51537cfc86a7cb3ef1c0a4c in the 4.2 branch).

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	[tests/inp_str.dat] Make the word that contains '\0' look like a number.

	Changed ".\0." to "1\01" (\0 being the null character) in order to
	trigger a failure with the current mpfr_inp_str code. The issue is
	that '\0' makes the word look like the string "1", the '\0' being
	regarded as a terminating null character. This is incorrect as '\0'
	is part of the full word.

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	[manual] Clarified the return value of mpfr_inp_str.

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	Added a '\0' test for mpfr_inp_str.

	After ensuring that isspace(0) is false, make sure that '\0' is
	handled as a normal non-whitespace character.

	Also note that inp_str.dat does not end with a newline character
	on purpose, in order to check that a number at the end of the file
	(with no whitespace after it) is handled correctly.

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	Improved the mpfr_inp_str tests.

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	[tests/inp_str.dat] Added the other standard whitespace characters.

	These are:
	  * space (' ');
	  * ^I (horizontal tab '\t');
	  * ^J (newline '\n', already there);
	  * ^K (vertical tab '\v');
	  * ^L (form feed '\f');
	  * ^M (carriage return '\r').

2023-07-12  Vincent Lefevre  <vincent@vinc17.net>

	[MPFR manual] Corrected description of mpfr_inp_str.

	The description seemed to assume that there was leading and trailing
	whitespace (due to "between whitespace"). Also clarify what whitespace
	is: defined by isspace(), which depends on the current locale.

2023-06-26  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tfpif.c] Workaround for GCC bug 106155.

	This GCC bug is:
	  [12/13/14 Regression] spurious "may be used uninitialized" warning

	This bug appeared in GCC 12, but it is more serious in GCC 13
	(at least for tfpif.c), which warns also at -O2:
	  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155#c12

	Silencing this warning avoids an error when -Werror is used.

2023-06-26  Vincent Lefevre  <vincent@vinc17.net>

	[src/pow.c] Typo detected by codespell.

2023-05-26  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tsprintf.c] Fixed large_prec_for_g with 32-bit mpfr_intmax_t.

	If mpfr_intmax_t is a 32-bit type (meaning that int is a 32-bit type
	too), then allow a failure on "%.2147483648Rg" (return value < 0),
	due to a (reasonable) limit on the current implementation.

	This can currently be tested with
	  -std=c90 -Werror -pedantic -Wformat -Wno-error=overlength-strings

2023-05-25  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tsprintf.c] large_prec_for_g: C++ compatibility.

	Note that after this change, the test is still meaningful.

2023-05-23  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tsprintf.c] Improved large_prec_for_g even more.

2023-05-23  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tsprintf.c] A few more tests for large_prec_for_g.

	... to really check that the results are correct.

2023-05-22  Vincent Lefevre  <vincent@vinc17.net>

	[tests/trec_sqrt.c] Updated bad_case3() test.

	Also check the result, though this is not the real purpose of
	this test (the purpose is to detect a stack overflow, which
	just makes the program crash).

2023-05-22  Vincent Lefevre  <vincent@vinc17.net>

	[tests/trec_sqrt.c] Added bad_case3() test.

	Simple hardcoded test for the stack overflow bug fixed on 2023-04-17
	in commits
	  270f4df6b3a49caae1cf564dcdc1c55b1c5989eb (master)
	  934dd8842b4bdeb919a73123203bc8ce56db38d1 (4.2 branch)

	Otherwise, this bug was triggered by a generic bad_cases() test,
	based on random values.

2023-05-22  Vincent Lefevre  <vincent@vinc17.net>

	[tests.c] In bad_cases(), improved alignment in debug messages.

	Needed as some trec_sqrt tests use a precision with up to 6 digits.

2023-05-17  Vincent Lefevre  <vincent@vinc17.net>

	[tcompound.c] Updated comment for bug_20230517.

	Similar to b8ee84929ef6caf66d7c694cf74534b7190339c5 in master.

2023-05-17  Vincent Lefevre  <vincent@vinc17.net>

	[compound.c] Improved tests and corresponding comment.

	[compound.c] Avoid a possible integer overflow; other improvements.

2023-05-17  Vincent Lefevre  <vincent@vinc17.net>

	[tcompound.c] Added bug_20230517 (integer overflow in compound.c).

	and updated comment for the 4.2 branch.

2023-05-16  Vincent Lefevre  <vincent@vinc17.net>

	[src/vasprintf.c] Fixed bug triggered by the large_prec_for_g test.

	Bug fixes in partition_number():
	* Fixed the type of the variable `threshold`: as this variable may
	  contain spec.prec, it needs to be of type mpfr_intmax_t.
	  This was the cause of the "MPFR assertion failed: threshold >= 1"
	  (or the incorrect size when assertions are not checked) with the
	  large_prec_for_g test.
	* Also make sure that the 4th argument given to mpfr_get_str fits
	  in a size_t (if it doesn't, return with a failure, as done when
	  reaching other environmental limits).
	  In practice, this could be an issue only with a 32-bit size_t and
	  mpfr_exp_t on more than 32 bits.

2023-05-16  Vincent Lefevre  <vincent@vinc17.net>

	[tests/tsprintf.c] Added large_prec_for_g, which makes MPFR crash.

	On a 64-bit Linux machine, the case %.2147483648Rg yields an incorrect
	size computation and MPFR wants to allocate 18446744071562070545 bytes.
	This case should either succeed or fail as reaching an environmental
	limit like with glibc (note that the precision does not fit in an int).

2023-05-16  Vincent Lefevre  <vincent@vinc17.net>

	[manual] Detailed mpfr_compound_si description (special cases).

	The MPFR manual should be self-contained. So, let's describe
	the special cases of mpfr_compound_si that do not follow the
	usual rules (or are ambiguous), instead of just referring to
	the IEEE 754 standard.

2023-05-16  Vincent Lefevre  <vincent@vinc17.net>

	[compound.c] Fixes concerning the overflow and underflow detection.

	Note: It is not clear whether overflow and underflow detection is
	now correct. There may still be potential issues, but currently,
	after these fixes, no tests yield any failure (however, we do not
	test some of the most problematic cases yet; this should be a
	future improvement of ofuf_thresholds in the master branch).

	Note: compound.c now corresponds to the version in master.

2023-05-16  Vincent Lefevre  <vincent@vinc17.net>

	[tcompound.c] Added various tests.

	* Added bug_20230206, based on a bug report by Patrick Pélissier.
	* Implemented the inverse function x^(1/n) - 1 of the compound function
	  on non-special cases: useful to build and check hard-to-round cases
	  and test the behavior close to the overflow and underflow thresholds.
	* Check hard-to-round cases for n = 2, 3, 4, 5, 17, 120 (like in tpow.c)
	  and also call the generic tests for these values.
	* Added bug_20230211 (buggy overflow detection for 32 bits after the
	  fix of bug_20230206 in master).

	and updated two comments for the 4.2 branch.

	Note: Every change has been cherry picked from master, except a
	TODO comment and the ofuf_thresholds() calls (feature not yet in
	the 4.2 branch). And bug_20230206 has not been fixed yet in the
	4.2 branch.

2023-05-15  Vincent Lefevre  <vincent@vinc17.net>

	[tests.c] In bad_cases(), handle the inex_inv case better.

	The "f exact while f^(-1) inexact" case is actually almost the same
	as the "inverse doesn't match" case. So, handle it in the same way,
	avoiding a fatal error (which would be bad for the non-developers):
	a few occurrences of this case should be regarded as normal, and if
	this occurs too often, this will be detected like the other case
	when the MPFR_CHECK_BADCASES environment variable is set.

	This is useful for future bad_cases() calls.

2023-05-12  Vincent Lefevre  <vincent@vinc17.net>

	[src/pow.c] Fixed a corner case in mpfr_pow_general (bug20230427).

	This fixes the bug triggered by bug20230427 added in commit 85bc7331c:
	  bug20230427 triggers another bug in mpfr_pow_general, which
	  occurs in destination precision 1 in the particular case of
	  rounding to nearest, z * 2^k = 2^(emin - 2) and real result
	  larger than this value.

	This corresponds to a particular hunk of a diff from master,
	or with a cherry-pick from commits
	  ef31bb98521ecf7d100593346e2f4d7a7724c573
	  27bc582645e513200c56c99a9da83eb4e47c669a
	  e1f9f14a3829081503c027f4d38eb51778da26e6
	  ff5012b61d5e5fee5156c57b8aa8fc1739c2a771
	  3b63024c640181cb5fe7fd87bac94a8f942a07da
	  4f5de980be290687ac1409aa02873e9e0dd1a030
	  467b17025a5b05e888ed7117d6730ac0954f01cb
	restoring the changes not related to this hunk.

2023-05-12  Vincent Lefevre  <vincent@vinc17.net>

	[src/pow.c] Fixed error bound in mpfr_pow_general (bug20230213).

	This fixes the bug triggered by bug20230213 added in commit 85bc7331c:
	  bug20230213 triggers a bug in mpfr_pow_general, where the
	  computation of the error term is incorrect when there has
	  been an intermediate underflow or overflow (k_non_zero is
	  true); the error analysis is correct, but the associated
	  code is not (due to the change of the value of a variable).

2023-05-12  Vincent Lefevre  <vincent@vinc17.net>

	[tests/texp10.c] Added bug20230213 and bug20230427 tests.

	* bug20230213 triggers a bug in mpfr_pow_general, where the
	  computation of the error term is incorrect when there has
	  been an intermediate underflow or overflow (k_non_zero is
	  true); the error analysis is correct, but the associated
	  code is not (due to the change of the value of a variable).
	* bug20230427 triggers another bug in mpfr_pow_general, which
	  occurs in destination precision 1 in the particular case of
	  rounding to nearest, z * 2^k = 2^(emin - 2) and real result
	  larger than this value.

	Note: The code has been copied from master (and because of changes
	of other parts of the code by commits in master, cherry-picking
	was impossible or much more complex). These bugs have been fixed
