Minimum floating-point requirements

[Joseph S. Myers]

On Thu, 30 Jan 2014, Steve Munroe wrote:

> Joseph I don't follow GCC closely these days and so am not clear about what
> you are proposing.
> 
> Can you point me to a bugzilla or change log?

http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00157.html

is the libgcc patch in question to avoid spurious internal overflows.  One 
of the fixes there is needed for cbrtl (LDBL_MAX) to work - but it seemed 
prudent to fix the whole class of issues rather than keep finding more 
cropping up as glibc test coverage improves and needing each time to track 
them back to a particular bug that could have been fixed earlier.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59666

is the issue for non-default rounding modes (where I suggested possibly 
having separate __gcc_*_round functions used only with -frounding-math, if 
the performance cost of saving and restoring the rounding mode is 
significant).

In addition to those two, there are various cases of spurious underflow 
exceptions when the final result of multiplication (probably division as 
well) is not in the subnormal long double range so should not have that 
exception.  These cause glibc test failures just as the other issues do.

I don't object to Mike Stump's suggestion in 
<http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01837.html> of an option 
-mieee (which would then be used automatically by the glibc build) to 
enable all these various fixes together (although since this is inherently 
not an IEEE floating-point format, the name -mieee seems a little odd - 
and I had previously been thinking in terms of the generic functions doing 
everything except allowing for different rounding modes, and wrappers that 
deal with those, rather than two full variant copies of each function).

(glibc note: for software floating point, another libc-exported 
reserved-namespace function would be needed for libgcc to use to change 
temporarily to round-to-nearest.  I'm minded to call it __feswapround, 
thinking of __swapround in the example code for the FENV_ROUND pragma in 
draft TS 18661-1.  This would only be needed for software floating point 
(and so need to be in e500 glibc for ABI compatibility), since for 
hardware floating point libgcc could use asms for changing the rounding 
mode.  Obviously this would now be a matter for 2.20 or later.)

-- 
Joseph S. Myers
joseph@codesourcery.com