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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- 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>, Carlos O'Donell <carlos at systemhalted dot org>, Mike Frysinger <vapier at gentoo dot org>
- Date: Tue, 25 Sep 2012 19:29:34 +0000
- Subject: Re: Architecture floating-point underflow information wanted
- References: <Pine.LNX.4.64.1209251238230.12872@digraph.polyomino.org.uk> <m2vcf2t1lk.fsf@igel.home>
On Tue, 25 Sep 2012, Andreas Schwab wrote:
> "Joseph S. Myers" <joseph@codesourcery.com> writes:
>
> > #include <fenv.h>
> > #include <stdio.h>
> >
> > volatile float a = 0x1.fffp-126;
> > volatile float b = 0x1.0008p-1;
> > volatile float c;
> >
> > int
> > main (void)
> > {
> > feclearexcept (FE_ALL_EXCEPT);
> > c = a * b;
> > if (fetestexcept (FE_UNDERFLOW))
>
> Does this really give the correct result for FLT_EVAL_METHOD != 0? I
> think for those archs you have to set the rounding mode to float to be
> accurate.
On such architectures, the multiplication is exact (in a wider evaluation
type) and the potential underflow occurs on conversion to float to be
stored in "volatile float c". It doesn't matter whether the operation
with potential underflow is multiplication or conversion to float; both
are operations with binary floating-point results, so are required to
detect tinyness the same way.
--
Joseph S. Myers
joseph@codesourcery.com