This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399

--- Comment #9 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Tue, 20 Jun 2017, vincent-gcc at vinc17 dot net wrote:

> > 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).

That wording defines what "normalized" is, so that values with maximum 
exponent in this case don't count as normalized because not all values 
with that exponent in the floating-point model are representable, and 
defines LDBL_MAX so that it doesn't need to be normalized (and in this 
case isn't, by that definition of normalized).  The definition of 
LDBL_MAX_EXP is unchanged; it still just requires 2^(LDBL_MAX_EXP-1) to be 
representable, without requiring it to be normalized.

> > 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.

That's not a normalized value, because not all values with exponent emax 
are representable in the type, so none of them are normalized.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]