Minimum floating-point requirements

[Joseph S. Myers]

Steve, I don't think I've seen any followup to this message 
<https://sourceware.org/ml/libc-alpha/2014-01/msg00714.html>.  As I note 
there, I'd be happy with Mike Stump's suggestion of a -mieee option (with 
whatever name the powerpc GCC maintainers might prefer) enabling use of 
new libgcc functions __gcc_qadd_ieee, __gcc_qsub_ieee, __gcc_qmul_ieee, 
__gcc_qdiv_ieee, where would have more careful treatment of exceptions 
(and in future of rounding modes) than the main _gcc_* functions.

-- 
Joseph S. Myers
joseph@codesourcery.com

On Thu, 30 Jan 2014, Joseph S. Myers wrote:

> 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