LDBL_MAX broken on i386
Bruce Evans
brde at optusnet.com.au
Tue Sep 25 20:47:08 UTC 2012
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
More information about the freebsd-numerics
mailing list