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: Steve Munroe <sjmunroe at us dot ibm dot com>
- Cc: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, David Edelsohn <dje dot gcc at gmail dot com>, <libc-alpha at sourceware dot org>
- Date: Fri, 7 Feb 2014 23:51:18 +0000
- Subject: Re: Minimum floating-point requirements
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnym4yN=7rLrm0RRtNN++T=xwx8r3MUKJOfz4r+H=Z9zd7Q at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1401300038120 dot 24633 at digraph dot polyomino dot org dot uk> <OF9FA4A0A3 dot 0CD33B43-ON86257C70 dot 0073531F-86257C70 dot 0073A4BB at us dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1401302108080 dot 12540 at digraph dot polyomino dot org dot uk>
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