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.) -- Joseph S. Myers jos...@codesourcery.com
