This is the mail archive of the
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: Thu, 30 Jan 2014 21:20:54 +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>
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?
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.
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
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