--- - branch: MAIN date: Thu Aug 1 02:06:31 UTC 2019 files: - new: '1.11' old: '1.10' path: src/lib/libc/gdtoa/Makefile.inc pathrev: src/lib/libc/gdtoa/Makefile.inc@1.11 type: modified - new: '1.2' old: 1.1.1.1 path: src/lib/libc/gdtoa/gdtoa_fltrnds.h pathrev: src/lib/libc/gdtoa/gdtoa_fltrnds.h@1.2 type: modified - new: '1.15' old: '1.14' path: src/lib/libc/gdtoa/gdtoaimp.h pathrev: src/lib/libc/gdtoa/gdtoaimp.h@1.15 type: modified id: 20190801T020631Z.c7795f090ecf89c6eaa71c2b821dcaab8919b522 log: | Honour the floating-point rounding mode in floating-point formatting. C99, Sec. 7.19.6.1 `The fprintf function', paragraph 13, p. 281: (Recommended practice) For e, E, f, F, g, and G conversions, if the number of significant decimal digits is at most DECIMAL_DIG, then the result should be correctly rounded. If the number of significant decimal digits is more than DECIMAL_DIG but the source value is exactly representable with DECIMAL_DIG digits, then the result should be an exact representation with trailing zeros. Otherwise, the source value is bounded by two adjacent decimal strings L < U, both having DECIMAL_DIG significant idgits; the value of the resultant decimal string D should satisfy L <= D <= U, _with the extra stipulation that the error should have a correct sign for the current rounding direction_. [emphasis added] The gdtoa code base already supports respecting the floating-point rounding mode, as long as we compile it with Honor_FLT_ROUNDS defined. However, for this to work, fegetround must be available in libc, which it is not currently -- the fenv logic is in libm. Fortunately, we don't have to move all of fenv from libm to libc -- programs that do not link against libm don't have fesetround, so the rounding mode is always the default (barring asm shenanigans that bypass the API -- tough). So use a weak reference to fegetround; by default, assume FE_TONEAREST if it is not defined. module: src subject: 'CVS commit: src/lib/libc/gdtoa' unixtime: '1564625191' user: riastradh