This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Minimum floating-point requirements
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Carlos O'Donell <carlos at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Thu, 30 Jan 2014 17:25:40 +0000
- Subject: Re: Minimum floating-point requirements
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401290320320 dot 2449 at digraph dot polyomino dot org dot uk> <52E9D943 dot 7010908 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1401301425160 dot 3467 at digraph dot polyomino dot org dot uk> <20140130170012 dot GV24286 at brightrain dot aerifal dot cx>
On Thu, 30 Jan 2014, Rich Felker wrote:
> long double that break basic floating point semantics. So I would at
> least encourage new ports to simply define long double as double
> unless there's support (or planned future support) for IEEE quad or an
> existing IEEE extended precision type (like ld80) at the hardware
> level.
Insofar as tools people have influence on hardware design (and at least
some instruction set designers do seek input on what features are or are
not good for compiler use), I'd encourage hardware designers to go for
IEEE binary128 instead of Intel (or m68k) "extended". While "extended" /
ldbl-96 follows IEEE semantics in terms of the set of values and the
operations on them, and so doesn't cause trouble for generic
floating-point code expecting IEEE semantics, the explicit "1" bit and
consequent presence of bit-patterns not representing any valid value of
the floating-point type do cause issues in some of the lower-level code
(the general position in glibc being that passing the invalid bit-patterns
- including those the hardware interprets as representing numbers, but
will not produce from arithmetic - to glibc functions is undefined
behavior).
--
Joseph S. Myers
joseph@codesourcery.com