https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> --- (In reply to jos...@codesourcery.com from comment #6) > The current proposed wording for DR#467 > <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2148.htm#dr_467> changes > "maximum representable finite floating-point number, [ math formula ]" to > "maximum representable finite floating-point number; if that value is > normalized, its value is [ math formula ],", which I think addresses the > first issue without requiring any change to LDBL_MAX_EXP; This change concerns the LDBL_MAX definition. However, there is another issue, related to the floating-point model 5.2.4.2.2p2 and p3. I assume that the intent of this definition is to require that *all* normalized floating-point numbers from this model are elements of the floating-point type (otherwise emin and emax would no longer make any sense). But with the current status, some floating-point numbers of exponent LDBL_MAX_EXP = 1024 (those with f54 = 1, if I'm not mistaken) are not elements of the type "long double". The reason is that the first double must be the exact value rounded to nearest (with the even rounding rule). > LDBL_MAX should > be the largest value, which in this case is not normalized, and > LDBL_MAX_EXP has nothing to do with what exponents do or not not have > normalized values. But the largest value must be at least the largest normalized value, which equals (1−b^(−p))b^emax. Currently, LDBL_MAX is smaller than this value. > It's true that GCC cannot handle IBM long double constants with more than > 106 mantissa bits, including the largest representable finite value. With the current LDBL_MAX_EXP definition, GCC can handle all values with 53 mantissa bits, but this becomes wrong for 54 mantissa bits.
