#1041 resync gdtoa with upstream

[Jameson]

Since I sync'd gdtoa with upstream, it looks like there's been some more changes: https://github.com/vtjnash/gdtoa/commit/c1460e389589aaed6b0236fab3136036cbb87546

The changelog (https://netlib.org/fp/changes) appears to state that this patch contains the following fixes:

20231209
Tweak to prevent spurious diagnostics, e.g., by
UndefinedBehaviorSanitizer: change
s1 = s;
while((c = ++s) >= '0' && c <= '9')
L = 10L + c - '0';
if (s - s1 > 8 || L > 19999)
to
while((c = ++s) >= '0' && c <= '9') {
if (L <= 19999)
L = 10L + c - '0';
}
if (L > 19999)
in dtoa.c, and in strtod.c and strtodg.c in gdtoa.tgz. Thanks to
Peter Hoddie peter@moddable.com for suggesting this change.

20240130
dtoa.c and gdtoa.tgz: Fix bug in strtod's handling of
0x1.fffffffffffffp-1023 which gave 0 rather than the expected
0x1p-1022. Thanks to Rick Regan (exploringbinary@gmail.com) for this
example.

20240202
dtoa.c and gdtoa.tgz: another try: fix bug in strtod's handling of
0x1.fffffffffffffp-1023 which gave 0 rather than the expected
0x1p-1022. The previous fix worked on that input, but broke some
other (denormal) inputs. Thanks again to Rick Regan
(exploringbinary@gmail.com) for providing examples.

20240206
dtoa.c and gdtoa.tgz: yet another try: fix bugs in strtod's
handling of hex input that should give 0x1p-1022. The previous fixes
sometimes worked, but broke some other (denormal) inputs. Thanks
again to Rick Regan (exploringbinary@gmail.com) for providing
examples.

20240207
dtoa.c and gdtoa.tgz: yesterday's fix to bugs in strtod's handling
of hex input that should give 0x1p-1022 broke rounding in other cases
of denormal input (due to a missing pair of parentheses). Thanks
again to Rick Regan (exploringbinary@gmail.com) for providing more
examples.

20240213
dtoa.c and gdtoa.tgz: fixes to some other cases of hexadecimal
input; adjust recent change for compilation with -DHonor_FLT_ROUNDS
-DTrust_FLT_ROUNDS. Thannks to Rick Regan (exploringbinary@gmail.com)
for providing more examples.

20240215
dtoa.c and gdtoa.tgz: fix a glitch that only matters when multiple
threads are in use.

20240221
dtoa.c and gdtoa.tgz: fix another glitch with nondefault rounding
modes and hexadecimal inputs near the smallest representable normal
number.

20240224
dtoa.c and gdtoa.tgz: fix yet another glitch with nondefault
rounding modes and hexadecimal inputs near the smallest representable
normal number. Thanks again to Rick Regan (exploringbinary@gmail.com)
for providing another example.

20260908
dtoa.c and gdtoa/misc.c: have Balloc set the "next" field in the
returned Bigint to 0, fixing a bug reported by Chris Cunningham
chris@abditory.io and allowing a couple of assignments of 0 to the
"next" field of a Bigint to be eliminated. (Those assignments were
too late.)
Update some of the *.out files in gdtoa/test to reflect numbers
added to the gdtoa/test/testnos file in the changes of 20111102.

20260911
Update more files in gdtoa/test to reflect numbers added to the
gdtoa/test/testnos file in the changes of 20111102.
Add -lm to some rules in gdtoa/test/makefile (need for fegetround
on some systems).
Added to gdtoa/README:
Addition (20260911) on double rounmding, based only on experience with
a Linux machine with an Intel x86_64 CPU... Use of 80-bit arithmetic
rounded to bits (long double to double) may give wrong results due to
double rounding. Compilations by "gcc -m32" and "clang -m32" (to use
32-bit addressing) have this property. Compilation by
"gcc -m32 -mfpmath=sse" uses 32-bit addressing but avoids double
rounding. The (current) default addressing for both gcc and clang is
-m64 (64-bit addressing) and uses SSE instructions, avoiding double
rounding. An input to strtod subject to double rounding when 80-bit
arithmetic is rounded to 64 bits is 8.3e26 (or the multiplication
83e13 times 1e12).

[Jonathan Yong]

Please send the patches to the mailing list for review, we do not do off-site discussions.

[Jameson]

I had only the upstream changes to report, not a patch to review. But it also turns out the upstream introduces several critical bugs, so I've sent patches for these upstream, and it might be worth waiting for a response from David upstream before syncing with it. The upstream fixes I sent him are https://github.com/vtjnash/gdtoa/compare/vtjnash:c1460e3...vtjnash:719291c

The draft of all the patches (the sync, followed by bugfixes) is attached.

One additional detail to note is that upstream switches on -DHonor_FLT_ROUNDS with the latest release tarball, which should be landed as a separate commit, if that is desired in here. It changes parsing results based on the global rounding mode.

[Jonathan Yong]

Send the patch to the public mailing list for discussion, by email. Not everyone subscribes to the SF forum/ticket.