Architecture floating-point underflow information wanted

Architecture floating-point underflow information wanted

[Joseph S. Myers]

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).)

You can identify the choice made by an architecture by running the 
following program.  The GCC and glibc versions used to build and run the 
program don't matter, but it's best to run this on hardware not an 
emulator since it's quite possible some emulators could get this sort of 
detail wrong.  It may also be possible to find this information in 
architecture manuals.

#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))
    puts ("before rounding");
  else
    puts ("after rounding");
  return 0;
}

I'm looking for information for the following architectures:

s390-32, s390-64
alpha
am33
hppa
ia64
m68k (classic)

I have the following information for architectures I have access to:

x86, x86_64: after rounding
powerpc32, powerpc64: before rounding
sh: after rounding
sparc32, sparc64: before rounding
arm: before rounding
m68k (coldfire): before rounding
mips32, mips64: after rounding

(Tile does not support the underflow exception so the question is 
inapplicable there; I propose to use "before rounding" as a default for 
such architectures for strto*.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Architecture floating-point underflow information wanted

[Andreas Schwab]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> m68k (classic)

According to the manual: before rounding.

M68000PRM, section 3.6.1 (p. 3-28): "At the completion of an arithmetic
operation, the intermediate result is checked to see if it is too small
to be represented as a normalized number in the selected precision. If
so, the underflow (UNFL) bit is set in the FPSR EXC byte."

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Architecture floating-point underflow information wanted

[Mark Salter]

> am33

after rounding according to test. I couldn't find anything definitive
in the manual.

Re: Architecture floating-point underflow information wanted

[Carlos O'Donell]

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.

Re: Architecture floating-point underflow information wanted

[Carlos O'Donell]

On Tue, Sep 25, 2012 at 11:17 AM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> 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.

Verified that PA-RISC 1.1 hardware is also after rounding according to
the manual.

I have not booted real 1.1 hardware to verify.

Cheers,
Carlos.

Re: Architecture floating-point underflow information wanted

[David Miller]

From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 25 Sep 2012 12:52:16 +0000

> #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))
>     puts ("before rounding");
>   else
>     puts ("after rounding");
>   return 0;
> }

Just confirming that this gives 'before rounding' on all sparcs I have
access to.

Re: Architecture floating-point underflow information wanted

[Andreas Krebbel]

On 25/09/12 14:52, Joseph S. Myers wrote:
> I'm looking for information for the following architectures:
> 
> s390-32, s390-64
> alpha
> am33
> hppa
> ia64
> m68k (classic)

Your testcase returns "before rounding" on System z. Should be the same for s390.

-Andreas-

Re: Architecture floating-point underflow information wanted

[Andreas Schwab]

"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.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Architecture floating-point underflow information wanted

[Joseph S. Myers]

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

Re: Architecture floating-point underflow information wanted

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 104 bytes --]

On Tuesday 25 September 2012 08:52:16 Joseph S. Myers wrote:
> ia64

test reports:
after rounding
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]