https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #2 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 7 Mar 2016, uweigand at gcc dot gnu.org wrote: > 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. Note that independent of that question whether the number is isinf or not depends only on the first double (which is not inf). So eventually just the folding is bogus - who knows.
