https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Vincent Lefèvre from comment #11) > In addition to the maximum exponent issue, for LDBL_MAX following the defect > report, instead of > > 0x1.fffffffffffff7ffffffffffff8p+1023 > > I would expect > > 0x1.fffffffffffff7ffffffffffffcp+1023 = DBL_MAX + DBL_MAX * DBL_EPSILON / 4 > > as it is larger (it has one more trailing 1) and representable. That isn't representable in the GCC internal representation, which pretends the type has fixed 106 bit precision (like double has 53 bit precision), 0x1.fffffffffffff7ffffffffffffcp+1023 needs 107 bit precision (and generally the type has variable precision). The only way around that would be to actually represent it in GCC internal representation as sum of two doubles and rewrite all operations on this mode to treat it specially. That is a lot of work and given that powerpc64le is switching from this floating point format to IEEE quad long double format, I'm certain nobody is willing to spend that much time (months) on it.
