Up to [cvs.NetBSD.org] / src / lib / libc / gdtoa
Request diff between arbitrary revisions
Keyword substitution: kv
Default branch: MAIN
Pull up following revision(s) (requested by riastradh in ticket #787): tests/lib/libc/stdio/t_printf.c: revision 1.17 tests/lib/libc/stdio/t_printf.c: revision 1.18 lib/libc/gdtoa/hdtoa.c: revision 1.13 tests/lib/libc/stdio/t_printf.c: revision 1.11 tests/lib/libc/stdio/t_printf.c: revision 1.12 tests/lib/libc/stdio/t_printf.c: revision 1.13 tests/lib/libc/stdio/t_printf.c: revision 1.14 tests/lib/libc/stdio/t_printf.c: revision 1.15 tests/lib/libc/stdio/t_printf.c: revision 1.16 tests/lib/libc/stdio/t_printf: Add a couple simple %La tests. PR lib/56937: printf(3) long double %a formatting is broken tests/lib/libc/stdio/t_printf: Fix %La test. 0xa.99ap+0 is closer to (long double)10.6 in x86 ld80 and in binary128 (and possibly more formats, haven't verified). tests/lib/libc/stdio/t_printf: Fix %a test the same way. tests/lib/libc/stdio/t_printf: Add another %La test. This one was adapted from the screw case shown in https://mail-index.netbsd.org/tech-userlevel/2020/04/11/msg012329.html which wasn't broken in our libc, but which nevertheless prompted us to commit a wrong and apparently untested patch that has rendered printf %La broken for the last four years, which is a little embarrassing. (The part of that patch that led to a buffer overrun has been worked around, so now the output is just incorrect.) PR lib/56937: printf(3) long double %a formatting is broken Revert various broken changes to printf %La (hldtoa). This reverts: hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core) hdtoa.c 1.11 (fix tyop) hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).) The underlying motivation for this change was that when ld128 is decomposed into 4x32 words, this hldtoa logic is broken. But we don't decompose ld128 into 4x32 words; we decompose it into 6x64 words. And the change, which was supposed to be a noop in our case of 2x64 words (or similar for x87 80-bit floating-point), broke it to the point of causing buffer overruns (PR 56247) which when worked around led to just incorrect output output (PR 56937). If we want to make the #ifdefs for 4x32 words work, that's fine, but we absolutely must have automatic test cases to detect this kind of regression because %La formatting is extremely important for diagnosing details of floating-point data since it doesn't involve rounding in binary formats. For now I've added some trivial tests; there is a more extensive test suite inside gdtoa that we need to wire up before anyone tries any other shenanigans in this code. PR lib/56937: printf(3) long double %a formatting is broken tests/lib/libc/stdio/t_printf: Fix another rounding error. Noted by kre. This doesn't break a passing test or fix a failed test, at least on x86 -- our printf produces `0x1.533p+3' for the double case and `0xa.99ap+0' for the long double case. But of the hexadecimal number literals that that start with 0x5 having three hexadigits to the right of the fractional point, 0x5.4cdp+1 closest to the IEEE 754 binary64, VAX D, x86 extended precision, and IEEE 754 binary128 floating-point numbers closest to 10.6. The reason is that the number 10.6 (or the nearest floating-point number in any format with enough precision) is: 101.0100 1100 1100|1100... * 2^1 = 0x5.4cc|c...p+1 If we round at the vertical bar to the _nearest_ output with three hexadigits of precision, the result is: 101.0100 1100 1101 * 2^1 = 0x5.4cdp+1 tests/lib/libc/stdio/t_printf: Fix typo in ld128 case. printf %La does not write the `L' suffix. tests/lib/libc/stdio/t_printf: Fix sign error in ld128 case. Also link back to where the test case came from.
Fix hdtoa() for VAX D floating point
Revert various broken changes to printf %La (hldtoa). This reverts: hdtoa.c 1.12 (PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core) hdtoa.c 1.11 (fix tyop) hdtoa.c 1.10 (Via enh at google dot com in tech-userlevel. Fix handling of EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).) The underlying motivation for this change was that when ld128 is decomposed into 4x32 words, this hldtoa logic is broken. But we don't decompose ld128 into 4x32 words; we decompose it into 6x64 words. And the change, which was supposed to be a noop in our case of 2x64 words (or similar for x87 80-bit floating-point), broke it to the point of causing buffer overruns (PR 56247) which when worked around led to just incorrect output output (PR 56937). If we want to make the #ifdefs for 4x32 words work, that's fine, but we absolutely must have automatic test cases to detect this kind of regression because %La formatting is extremely important for diagnosing details of floating-point data since it doesn't involve rounding in binary formats. For now I've added some trivial tests; there is a more extensive test suite inside gdtoa that we need to wire up before anyone tries any other shenanigans in this code. PR lib/56937: printf(3) long double %a formatting is broken
PR/56247: Greg A. Woods: printf("%La", LDBL_MIN) dumps core Don't write to ((char *)malloc(size))[-1];
Sync with HEAD
fix tyop
Via enh at google dot com in tech-userlevel. Fix handling of EXT_FRAC{H,L}BITS (although we don't need to since we don't have them).
avoid some uninitalised variable warnings.
Don't use #endif where #else is expected.
pacify lint.
Sync with netbsd-4.
Pull up revisions: src/lib/libc/gdtoa/dmisc.c 1.4 src/lib/libc/gdtoa/gdtoa.c 1.4 src/lib/libc/gdtoa/gethex.c 1.4 src/lib/libc/gdtoa/misc.c 1.4 src/lib/libc/gdtoa/strtof_vaxf.c 1.4-1.5 src/lib/libc/gdtoa/strtopQ.c 1.4 src/lib/libc/gdtoa/strtopx.c 1.4 src/lib/libc/gdtoa/strtopxL.c 1.4 src/lib/libc/gdtoa/strtord.c 1.4 src/lib/libc/gdtoa/dtoa.c 1.5 src/lib/libc/gdtoa/strtod.c 1.5 src/lib/libc/gdtoa/g_Qfmt.c 1.3 src/lib/libc/gdtoa/g_xLfmt.c 1.3 src/lib/libc/gdtoa/g_xfmt.c 1.3 src/lib/libc/gdtoa/smisc.c 1.3 src/lib/libc/gdtoa/strtof.c 1.3 src/lib/libc/gdtoa/strtorQ.c 1.3 src/lib/libc/gdtoa/strtorx.c 1.3 src/lib/libc/gdtoa/strtorxL.c 1.3 src/lib/libc/gdtoa/g_ddfmt.c 1.2 src/lib/libc/gdtoa/g_dfmt.c 1.2 src/lib/libc/gdtoa/g_ffmt.c 1.2 src/lib/libc/gdtoa/strtoIQ.c 1.2 src/lib/libc/gdtoa/strtoId.c 1.2 src/lib/libc/gdtoa/strtoIdd.c 1.2 src/lib/libc/gdtoa/strtoIf.c 1.2 src/lib/libc/gdtoa/strtoIg.c 1.2 src/lib/libc/gdtoa/strtoIx.c 1.2 src/lib/libc/gdtoa/strtoIxL.c 1.2 src/lib/libc/gdtoa/strtodI.c 1.2 src/lib/libc/gdtoa/strtodnrp.c 1.2 src/lib/libc/gdtoa/strtopd.c 1.2 src/lib/libc/gdtoa/strtopdd.c 1.2 src/lib/libc/gdtoa/strtopf.c 1.2 src/lib/libc/gdtoa/strtordd.c 1.2 src/lib/libc/gdtoa/strtorf.c 1.2 src/lib/libc/gdtoa/sum.c 1.2 src/lib/libc/gdtoa/gdtoa.h 1.8 src/lib/libc/gdtoa/hdtoa.c 1.6 src/lib/libc/gdtoa/strtodg.c 1.6 src/lib/libc/stdio/vfwprintf.c 1.12 (requested by mjf ticket #1120). Don't coredump on out of memory conditions. This solution leaks, but gdtoa is too complicated to fix. Try printf %99999999999.9999999999f 2 Make this build again.
Pull up revisions: src/lib/libc/gdtoa/dmisc.c 1.4 src/lib/libc/gdtoa/gdtoa.c 1.4 src/lib/libc/gdtoa/gethex.c 1.4 src/lib/libc/gdtoa/misc.c 1.4 src/lib/libc/gdtoa/strtof_vaxf.c 1.4-1.5 src/lib/libc/gdtoa/strtopQ.c 1.4 src/lib/libc/gdtoa/strtopx.c 1.4 src/lib/libc/gdtoa/strtopxL.c 1.4 src/lib/libc/gdtoa/strtord.c 1.4 src/lib/libc/gdtoa/dtoa.c 1.5 src/lib/libc/gdtoa/strtod.c 1.5 src/lib/libc/gdtoa/g_Qfmt.c 1.3 src/lib/libc/gdtoa/g_xLfmt.c 1.3 src/lib/libc/gdtoa/g_xfmt.c 1.3 src/lib/libc/gdtoa/smisc.c 1.3 src/lib/libc/gdtoa/strtof.c 1.3 src/lib/libc/gdtoa/strtorQ.c 1.3 src/lib/libc/gdtoa/strtorx.c 1.3 src/lib/libc/gdtoa/strtorxL.c 1.3 src/lib/libc/gdtoa/g_ddfmt.c 1.2 src/lib/libc/gdtoa/g_dfmt.c 1.2 src/lib/libc/gdtoa/g_ffmt.c 1.2 src/lib/libc/gdtoa/strtoIQ.c 1.2 src/lib/libc/gdtoa/strtoId.c 1.2 src/lib/libc/gdtoa/strtoIdd.c 1.2 src/lib/libc/gdtoa/strtoIf.c 1.2 src/lib/libc/gdtoa/strtoIg.c 1.2 src/lib/libc/gdtoa/strtoIx.c 1.2 src/lib/libc/gdtoa/strtoIxL.c 1.2 src/lib/libc/gdtoa/strtodI.c 1.2 src/lib/libc/gdtoa/strtodnrp.c 1.2 src/lib/libc/gdtoa/strtopd.c 1.2 src/lib/libc/gdtoa/strtopdd.c 1.2 src/lib/libc/gdtoa/strtopf.c 1.2 src/lib/libc/gdtoa/strtordd.c 1.2 src/lib/libc/gdtoa/strtorf.c 1.2 src/lib/libc/gdtoa/sum.c 1.2 src/lib/libc/gdtoa/gdtoa.h 1.8 src/lib/libc/gdtoa/hdtoa.c 1.6 src/lib/libc/gdtoa/strtodg.c 1.6 src/lib/libc/stdio/vfwprintf.c 1.12 (requested by mjf ticket #1120). Don't coredump on out of memory conditions. This solution leaks, but gdtoa is too complicated to fix. Try printf %99999999999.9999999999f 2 Make this build again.
Don't coredump on out of memory conditions. This solution leaks, but gdtoa is too complicated to fix. Try printf %99999999999.9999999999f 2
Pull up following revision(s) (requested by mhitch in ticket #646): lib/libc/gdtoa/hdtoa.c: revision 1.5 sys/arch/vax/include/vaxfp.h: revision 1.6 deal with the vax in a slightly disgusting way. Provide constants for the widths of the bitfields and use them.
Pull up following revision(s) (requested by manu in ticket #607): lib/libc/arch/i386/gen/isnanl.c: revision 1.6 lib/libc/gdtoa/gdtoa.c: revision 1.2-1.3 lib/libc/arch/x86_64/gen/isnanl.c: revision 1.6 lib/libc/gdtoa/gdtoaimp.h: revision 1.6 sys/arch/m68k/include/ieee.h: revision 1.13 usr.bin/xlint/lint1/scan.l: revision 1.36-1.37 lib/libc/stdio/snprintf_ss.c: revision 1.4 lib/libc/arch/i386/gen/isfinitel.c: revision 1.2 lib/libc/stdio/vfscanf.c: revision 1.38 sys/arch/sparc/include/ieee.h: revision 1.11-1.12 lib/libc/gdtoa/dtoa.c: revision 1.4 lib/libc/stdio/Makefile.inc: revision 1.35 lib/libc/stdio/fvwrite.c: revision 1.17 lib/libc/arch/m68k/gen/fpclassifyl.c: revision 1.2 lib/libc/arch/i386/gen/isinfl.c: revision 1.6 lib/libc/arch/x86_64/gen/isinfl.c: revision 1.6 lib/libc/arch/x86_64/gen/isfinitel.c: revision 1.2 lib/libc/stdio/vfprintf.c: revision 1.55-1.57 lib/libc/stdio/vsnprintf_ss.c: revision 1.3 lib/libc/stdio/vfwprintf.c: revision 1.10 sys/arch/x86/include/ieee.h: revision 1.10 lib/libc/gdtoa/dmisc.c: revision 1.3 lib/libc/gdtoa/Makefile.inc: revision 1.5 sys/arch/hppa/include/ieee.h: revision 1.10 lib/libc/arch/x86_64/gen/fpclassifyl.c: revision 1.3 lib/libc/arch/i386/gen/fpclassifyl.c: revision 1.2 sys/sys/ieee754.h: revision 1.7 lib/libc/gdtoa/gdtoa.h: revision 1.7 include/stdio.h: revision 1.67-1.68 lib/libc/gdtoa/hdtoa.c: revision 1.1-1.4 lib/libc/gdtoa/ldtoa.c: revision 1.1-1.4 defined(_NETBSD_SOURCE) is equivalent to (!defined(_ANSI_SOURCE) && !defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE)), so there's no need to check both of them. Fix for issue reported in PR lib/35401 as well as related overflow bugs. deal with hex doubles. Instead of abusing stdio to get a signal-safe version of sprintf, provide one. remove __SAFE add long double and hex double support from freebsd. make this compile. add new prototypes. add the new files to the build. Note I am not bumping libc now, because these are not used yet. Merge the int bit with the high fraction bit. Add constants/macros needed by gdtoa. add constants used by gdtoa since the int bit is merged, do the explicit math. ext_int bit is no more. ext_int bit is no more. - merge change from freebsd - add support for building as vfprintf.c - XXX: we strdup to simplify the freeing logic. This should be fixed for efficiency in the vfprintf case. use vfwprintf.c enable wide doubles. some int -> size_t deal with sparc64 that has 112 bits of mantissa. make extended precision gdtoa friendly. int/size_t changes make this gdtoa friendly. remove dup definition use dtoa() instead of returning empty when we don't have extended precision information. Fix previous, add forgotten pointer dereference in the call to dtoa(). Add a cheesy workaround marked XXX for the situation where the strtod() implementation available in the environment does not handle hex floats. Discussed with and suggested by christos From Christos: gdtoa fixes for m68k. M68k ports should build now, but printing extended precision is a little off. vax does not have <machine/ieee.h> or long double It would be nice if the compiler provided something like __IEEE_MATH__ bring in FreeBSD's vfscanf() to gain multi-byte/collation support. Unfortunately it is too difficult to make vfwscanf and this share the same code like I did with printf, because for string parsing the code is too different.
file hdtoa.c was added on branch netbsd-4 on 2007-05-07 19:49:06 +0000
deal with the vax in a slightly disgusting way.
vax does not have <machine/ieee.h> or long double It would be nice if the compiler provided something like __IEEE_MATH__
int/size_t changes
some int -> size_t deal with sparc64 that has 112 bits of mantissa.
add long double and hex double support from freebsd.