This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Architecture floating-point underflow information wanted
- From: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: libc-alpha at sourceware dot org, libc-ports at sourceware dot org, Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, Richard Henderson <rth at twiddle dot net>, Mark Salter <msalter at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Andreas Schwab <schwab at linux-m68k dot org>
- Date: Tue, 25 Sep 2012 11:17:54 -0400
- Subject: Re: Architecture floating-point underflow information wanted
- References: <Pine.LNX.4.64.1209251238230.12872@digraph.polyomino.org.uk>
On Tue, Sep 25, 2012 at 8:52 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> As part of fixing bug 14047, I'd like information about how each glibc
> architecture (libc and ports) detects floating-point underflow. (IEEE
> 754-2008 gives two options: "before rounding" (exponent would be below
> normal range if both exponent range and mantissa precision were unbounded)
> and "after rounding" (exponent of the rounded value would be below normal
> range if the exponent range were unbounded and values with all exponents
> had the same mantissa precision as for normal values).)
Thanks for the test case.
> I'm looking for information for the following architectures:
>
> s390-32, s390-64
> alpha
> am33
> hppa
> ia64
> m68k (classic)
hppa (64-bit PA-RISC 2.0) is after rounding according to the test.
The manual says:
~~~
Tininess is detected on a nonzero result which lies strictly between
+/-2^(Emin), when the result is rounded as if the exponent range were
unbounded.
~~~
Thus verified by what the manual says.
Cheers,
Carlos.