LDBL_MAX broken on i386

[Bruce Evans]

On Mon, 24 Sep 2012, Steve Kargl wrote:

> On Tue, Sep 25, 2012 at 08:28:34AM +1000, Bruce Evans wrote:
> ...
>> LDBL_MAX stopped working with this change to gcc.  From gcc/ChangeLog-
>> 2003:
>>
>> % 2003-07-01  Richard Henderson  <rth at redhat.com>
>> % 	    (blame to: Loren James Rittle  <ljrittle at acm.org>)
>> %
>> % 	* real.h (ieee_extended_intel_96_round_53_format): New.
>> % 	* real.c (ieee_extended_intel_96_round_53_format): New.
>> % 	* config/i386/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Use it
>> % 	for XFmode and TFmode.
>>
>> This was well enough discussed in FreeBSD lists before it was committed
>> (or even developed?), and I agreed with it at the time, but didn't
>> understand its full awfulness.  gcc-4.2.1 still hard-configures the
>> flag that enables this: from gcc/config/freebsd.h:
>>
>> % /* FreeBSD sets the rounding precision of the FPU to 53 bits.  Let the
>> %    compiler get the contents of <float.h> and std::numeric_limits correct.  */
>> % #undef  TARGET_96_ROUND_53_LONG_DOUBLE
>> % #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT)
>
> I just checked the head of gcc, the above is still present.
> This suggests to me that i386 FreeBSD will never be free of
> the npx feature of setting the FPU to 53 bits.

We can always change it in our version.

>> so i386 always gets it and amd64 never does.  There seems to be no way to
>> get 53-bit rounding for expressions without getting it for literals.
>
> I think you're correct about literals.  gcc, since about version
> 4.5.x, uses MPFR to do constant-folding and it does this in the
> precision of literal constant as determined by gcc.  On the bright
> side, MPFR claims to correctly round the folding.

I thought it already used something sophisticated with correct rounding
to do constant folding.

> ...
>> So gcc's values are perfectly consistent, but are correct if no one
>> ever creates values with the lower 11 bits set.
>
> So, if I understand the above, should we try to correct float.h
> to have 21 (36) digits on ld80 (ld128)?  Doing we limit LDBL_MAX
> on i386 to 2**(emax - 11)?

17 digits are enough on i386.  Extras are harmless if correctly rounded.
ld128 has 1 extra but I think with correct rounding.  The most critical
change is the last one.  Except it is wrong for clang.  The predefines
can be used to agreee with the compiler, but I prefer to see the actual
values in float.h.  That means idefs are required for clang.  Several
other ifdefs are required for clang.

Bruce