On 21/07/20 20:08 +0000, Joseph Myers wrote:
On Tue, 21 Jul 2020, Jonathan Wakely via Gcc-patches wrote:
I also noticed some strings give an underflow error with glibc's
strtod, but are valid for the Microsoft implementation. For example,
this one:
https://github.com/microsoft/STL/blob/master/tests/std/tests/P0067R5_charconv/double_from_chars_test_cases.hpp#L265
Without the final '1' digit glibc returns DBL_MIN, but with the final
'1' digit (so a number larger than DBL_MIN) it underflows. Is that
expected?
That's DBL_TRUE_MIN, not DBL_MIN. The IEEE rule is that, with default
exception handling, an exact subnormal result does not raise the underflow
exception flag, whereas an inexact tiny result raises both inexact and
underflow flags; glibc mostly doesn't try to ensure an (exact) underflow
exception is signaled for the case of exact underflow with traps on that
exception enabled, only correct flags raised with default exception
handling.
(The way tininess is determined depends on the architecture. glibc strtod
handles both cases, before-rounding and after-rounding architectures,
modulo oddities where implementations of some CPU architectures don't
appear to be consistent in their before-rounding / after-rounding choice.
Note that on after-rounding architectures it depends on the result after
rounding with normal precision but unbounded exponent range. One
consequence of that is that the bound on the number of digits after the
decimal point that may need to be considered, beyond just knowing whether
any of them are nonzero, to determine the correctly rounded result and
exceptions, is e.g. 1076 for binary64, not 1075; that is, two digits are
needed beyond those needed for an exact representation of the least
subnormal value, although only one such digit is needed for the correctly
rounded result if you ignore after-rounding tininess detection.)
Aha, thanks very much for the explanation.
