Re: Minimum floating-point requirements

["Carlos O'Donell" <carlos at redhat dot com>]

On 01/28/2014 10:35 PM, Joseph S. Myers wrote:
> I propose the following as minimum requirements on the underlying 
> floating-point arithmetic used in glibc (libc and libm) (this is about 
> float / double / long double rather than any other types; in particular, 
> complex multiplication / division in libgcc follows lower standards and is 
> generally avoided in glibc):
> 
> * No support for new formats not following IEEE semantics should be added.
> 
> * glibc code may always assume that floating-point arithmetic follows, at 
> least, similar standards to those applied to most libm functions, 
> regarding results being within a few ulps and exceptions other than maybe 
> "inexact" (and underflow for tiny exact results) being accurate.
> 
> * For IEEE formats, glibc code may assume that results are correctly 
> rounded with correct exceptions, subject to (a) processors not necessarily 
> supporting all rounding modes and exceptions, (b) GCC, kernel and 
> processor bugs, where the decision about whether to work around such a bug 
> is made on a case-by-case basis.  GCC should be used in a mode providing 
> this (bearing in mind that most glibc functions do not need "inexact"), 
> and the default FPU mode should be set similarly (to provide correct 
> results using kernel helpers, where necessary, for example).  (If "fast" 
> versions of functions are provided in future, or versions that require 
> round-to-nearest, etc., they can of course be built with different 
> options.)
> 
> * As a consequence of the above, we should seek FSF approval to copy the 
> IBM long double support from libgcc into glibc, under LGPLv2.1+, so that 
> it can be adapted to meet the above standards.
> 
> Comments?

All of these comments seem sensible to me.

However, I think new ports do have the right to approach the community
to discuss why they may want to *not* use an IEEE format. The new port
would have to clearly explain their position and user requirements,
since a non-IEEE format is difficult to maintain in a unified framework
that relies on IEEE semantics.

Do we have a wiki page describing the policies for new ports?

Cheers,
Carlos.