https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
Ulrich Weigand <uweigand at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gcc dot gnu.org,
| |dje at gcc dot gnu.org,
| |uweigand at gcc dot gnu.org
--- Comment #1 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
Hmm. For some reason, the gnulib definition of LDBL_MAX differs from GCC's
definition. With gnulib, we get:
high double: 7FEFFFFF FFFFFFFF
low double: 7C8FFFFF FFFFFFFF
while with GCC, we get:
high double: 7FEFFFFF FFFFFFFF
low double: 7C8FFFFF FFFFFFFE
In any case, someone is wrong here -- values of LDBL_MAX should certainly
agree.
Now I'm not completely sure why GCC choses the value it does, I notice that
GCC's choice is certainly deliberate; there's extra code to flip the last bit:
real.c:get_max_float
if (fmt->pnan < fmt->p)
{
/* This is an IBM extended double format made up of two IEEE
doubles. The value of the long double is the sum of the
values of the two parts. The most significant part is
required to be the value of the long double rounded to the
nearest double. Rounding means we need a slightly smaller
value for LDBL_MAX. */
buf[4 + fmt->pnan / 4] = "7bde"[fmt->pnan % 4];
}
and similarly real.c:real_maxval
if (fmt->pnan < fmt->p)
/* This is an IBM extended double format made up of two IEEE
doubles. The value of the long double is the sum of the
values of the two parts. The most significant part is
required to be the value of the long double rounded to the
nearest double. Rounding means we need a slightly smaller
value for LDBL_MAX. */
clear_significand_bit (r, SIGNIFICAND_BITS - fmt->pnan - 1);
This code was originally added by Alan back in 2004 ... adding Alan on CC if he
recalls what this was all about.
