Now
netbsd-9 commitmail json YAML
src/lib/libc/gdtoa/Makefile.inc@1.10.28.1
/
diff
/
nxr@1.10.28.1
src/lib/libc/gdtoa/gdtoa_fltrnds.h@1.1.1.1.46.1 / diff / nxr@1.1.1.1.46.1
src/lib/libc/gdtoa/gdtoaimp.h@1.14.30.1 / diff / nxr@1.14.30.1
src/lib/libc/gdtoa/gdtoa_fltrnds.h@1.1.1.1.46.1 / diff / nxr@1.1.1.1.46.1
src/lib/libc/gdtoa/gdtoaimp.h@1.14.30.1 / diff / nxr@1.14.30.1
Pull up following revision(s) (requested by riastradh in ticket #506):
lib/libc/gdtoa/Makefile.inc: revision 1.11
lib/libc/gdtoa/gdtoa_fltrnds.h: revision 1.2
lib/libc/gdtoa/gdtoaimp.h: revision 1.15
lib/libc/gdtoa/gdtoaimp.h: revision 1.17
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.
Mark the libc fegetround weak reference unused.
Not all .c files that include gdtoaimp.h use it, which makes clang
unhappy.
lib/libc/gdtoa/Makefile.inc: revision 1.11
lib/libc/gdtoa/gdtoa_fltrnds.h: revision 1.2
lib/libc/gdtoa/gdtoaimp.h: revision 1.15
lib/libc/gdtoa/gdtoaimp.h: revision 1.17
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.
Mark the libc fegetround weak reference unused.
Not all .c files that include gdtoaimp.h use it, which makes clang
unhappy.