Re: math broken on mips

Re: math broken on mips

[Stephen L Moshier]

> pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD
>                = 64.1547.. when rounding = DOWNWARD or TOWARDZERO

The libm functions from IBM that were recently installed in glibc come
with this remark in sysdeps/ieee754/dbl-64/MathLib.h:

  /* Assumption: Machine arithmetic operations are performed in       */
  /* round nearest mode of IEEE 754 standard.                         */

These math functions use a doubled-precision Dekker arithmetic which is
very sensitive to rounding rules and arithetic flaws.  Fixing the
routines to give reasonable answers with other rounding modes would not
be practical.

It is customary for a system math library to expect default environment
conditions, and I do not think this design actually violates any
standards. If you want to use non-default arithmetic settings and have
them work portably on various systems, you will have to take defensive steps
to protect your program from damage by the operating system and the system
library.

Re: math broken on mips

[Stephen L Moshier]

> pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD
>                = 64.1547.. when rounding = DOWNWARD or TOWARDZERO

The libm functions from IBM that were recently installed in glibc come
with this remark in sysdeps/ieee754/dbl-64/MathLib.h:

  /* Assumption: Machine arithmetic operations are performed in       */
  /* round nearest mode of IEEE 754 standard.                         */

These math functions use a doubled-precision Dekker arithmetic which is
very sensitive to rounding rules and arithetic flaws.  Fixing the
routines to give reasonable answers with other rounding modes would not
be practical.

It is customary for a system math library to expect default environment
conditions, and I do not think this design actually violates any
standards. If you want to use non-default arithmetic settings and have
them work portably on various systems, you will have to take defensive steps
to protect your program from damage by the operating system and the system
library.

Re: math broken on mips

[Geoff Keating]

> Mailing-List: contact libc-alpha-help@sources.redhat.com; run by ezmlm
> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-geoffk=redhat.com@sources.redhat.com>
> List-Subscribe: <mailto:libc-alpha-subscribe@sources.redhat.com>
> List-Archive: <http://sources.redhat.com/ml/libc-alpha/>
> List-Post: <mailto:libc-alpha@sources.redhat.com>
> List-Help: <mailto:libc-alpha-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
> Date: Mon, 18 Feb 2002 14:50:30 -0500 (EST)
> From: Stephen L Moshier <moshier@moshier.net>
> Reply-To: moshier@moshier.net
> cc: linux-mips@oss.sgi.com, <libc-alpha@sources.redhat.com>
> 
> 
> > pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD
> >                = 64.1547.. when rounding = DOWNWARD or TOWARDZERO
> 
> The libm functions from IBM that were recently installed in glibc come
> with this remark in sysdeps/ieee754/dbl-64/MathLib.h:
> 
>   /* Assumption: Machine arithmetic operations are performed in       */
>   /* round nearest mode of IEEE 754 standard.                         */
> 
> These math functions use a doubled-precision Dekker arithmetic which is
> very sensitive to rounding rules and arithetic flaws.  Fixing the
> routines to give reasonable answers with other rounding modes would not
> be practical.
> 
> It is customary for a system math library to expect default environment
> conditions, and I do not think this design actually violates any
> standards. If you want to use non-default arithmetic settings and have
> them work portably on various systems, you will have to take defensive steps
> to protect your program from damage by the operating system and the system
> library.

... actually, C99 seems to imply that all supported rounding
precisions should work for the math library, although of course C99
doesn't promise very much about accuracy of the math library in the
first place.

Maybe we should add appropriate fesetround() calls to the math
library?  Usually most of each routine should be done with
round-to-nearest and then there's one or two operations at the end
that should be in the user's rounding mode, to get the
correctly-rounded value for the user's rounding mode.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: math broken on mips

[Stephen L Moshier]

On Mon, 18 Feb 2002, Geoff Keating wrote:

> ... actually, C99 seems to imply that all supported rounding
> precisions should work for the math library

Could you point out specifically where it says that?

Re: math broken on mips

[Stephen L Moshier]

On Mon, 18 Feb 2002, Geoff Keating wrote:

> ... actually, C99 seems to imply that all supported rounding
> precisions should work for the math library

Could you point out specifically where it says that?

Re: math broken on mips

[Geoff Keating]

> Date: Mon, 18 Feb 2002 15:23:34 -0500 (EST)
> From: Stephen L Moshier <moshier@moshier.net>

> On Mon, 18 Feb 2002, Geoff Keating wrote:
> 
> > ... actually, C99 seems to imply that all supported rounding
> > precisions should work for the math library
> 
> Could you point out specifically where it says that?

It would have to specifically say that it doesn't, and I can't find
that.  For example, in s. 7.12.1 para 4, it says that HUGE_VAL is
a guaranteed result only in the default rounding mode.  

Appendix F says, in s. F.9 para 10, "Whether the [elementary]
functions honour the rounding direction mode is
implementation-defined." but this doesn't allow the functions to
produce invalid results, just to ignore the mode and use some other
mode instead.  A good math library should honour the current rounding
mode, as this is what is most useful.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: math broken on mips

[Stephen L Moshier]

> Appendix F says, in s. F.9 para 10, "Whether the [elementary]
> functions honour the rounding direction mode is
> implementation-defined."

Does the glibc documentation define it?

Re: math broken on mips

[Stephen L Moshier]

> Appendix F says, in s. F.9 para 10, "Whether the [elementary]
> functions honour the rounding direction mode is
> implementation-defined."

Does the glibc documentation define it?

Re: math broken on mips

[Ulrich Drepper]

Stephen L Moshier <moshier@moshier.net> writes:

> Does the glibc documentation define it?

No version of any math library reliably worked with anything but
round-to-nearest.  Only functions which were implemented using integer
operations were immune and this set varied among different platforms.
It's not written down but was always said.  If somebody wants to add
it to the documentation s/he can write something up.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: math broken on mips

[Ulrich Drepper]

Stephen L Moshier <moshier@moshier.net> writes:

> Does the glibc documentation define it?

No version of any math library reliably worked with anything but
round-to-nearest.  Only functions which were implemented using integer
operations were immune and this set varied among different platforms.
It's not written down but was always said.  If somebody wants to add
it to the documentation s/he can write something up.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: math broken on mips

[Ulrich Drepper]

Geoff Keating <geoffk@geoffk.org> writes:

> Maybe we should add appropriate fesetround() calls to the math
> library?

No, this would punish the people who do not do stupid things with
rounding modes.  The user must know much better where such changes are
needed.

As you mentioned, there is no promise of precision in the standard
therefore everything is just fine as it is, standard-wise.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: math broken on mips

[Andreas Schwab]

Geoff Keating <geoffk@geoffk.org> writes:

|> ... actually, C99 seems to imply that all supported rounding
|> precisions should work for the math library

Only if #pragma STDC FENV_ACCESS "on" is in effect.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

math broken on mips

[Zhang Fuxin]

hi,
   There are so many problems on math handling for linux-mips,including:
1. SNaN & QNan handling(both gcc & glibc)
2. gcc2.96 generates wrong code with -O2,at least 
     one will lead to exception handling problem(reported by me)
     one will lead to some 'long long' type mishandling(reported by Atsushi Nemoto)

   (gcc3.1 seems a lot better,but it has problem to compile glibc.I can't even compile
 current glibc cvs code(with dl-conflict.c etc patched) with it. The best result is
 a segment fault when using ld.so.1:
      ../elf/ld.so.1 --library-path ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv:
  ../crypt:../linuxthreads ./rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o 
  xbootparam_prot.T
  make[1]: *** [xbootparam_prot.stmp] Segmentation fault
  )     
3. problems with math-emu
4. other problems to be investigated for its cause,including this one,
  
       pow(2,7) = 128.0 when rounding = TONEAREST or UPWARD
                = 64.1547.. when rounding = DOWNWARD or TOWARDZERO

 when today i find out the above problem I was feeling almost despaired:(

 I want to fix these problems,if i could.But it concerns so many things that i am not
 expert on and no time to dig:(. So any help will be highly appreciated.

 


Regards
            Zhang Fuxin
            fxzhang@ict.ac.cn

Re: math broken on mips

[H . J . Lu]

On Mon, Feb 18, 2002 at 03:57:04PM +0800, Zhang Fuxin wrote:
> 
>    (gcc3.1 seems a lot better,but it has problem to compile glibc.I can't even compile
>  current glibc cvs code(with dl-conflict.c etc patched) with it. The best result is
>  a segment fault when using ld.so.1:
>       ../elf/ld.so.1 --library-path ..:../math:../elf:../dlfcn:../nss:../nis:../rt:../resolv:
>   ../crypt:../linuxthreads ./rpcgen -Y ../scripts -c rpcsvc/bootparam_prot.x -o 
>   xbootparam_prot.T

You need to get the current glibc/gcc from CVS. You also need to apply
my glibc patches for mips if they are not in CVS yet. They are:

2002-01-20  H.J. Lu  <hjl@gnu.org>

        * config.make.in (inline-limit): New.

        * configure.in: Check if gcc supports -finline-limit=xxx.
        * configure: Rebuild.

        * elf/Makefile (CFLAGS-rtld.c): Set to -finline-limit=2000 if
        needed.

2002-02-04  H.J. Lu  <hjl@gnu.org>

        * elf/dl-conflict.c (_dl_resolve_conflicts): Dummy if
        _DL_HAVE_NO_ELF_MACHINE_RELA is defined.

2001-07-10  H.J. Lu  <hjl@gnu.org>

        * sysdeps/unix/sysv/linux/powerpc/mmap64.c: Moved to ...
        * sysdeps/unix/sysv/linux/mmap64.c: Here.

        * sysdeps/unix/sysv/linux/mmap64.c (MMAP2_PAGE_SHIFT): Renamed
        from PAGE_SHIFT. Define if not defined. Check MMAP2_PAGE_SHIFT
        only if __NR_mmap2 is defined.

        * sysdeps/unix/sysv/linux/hppa/mmap64.c : Removed.
        * sysdeps/unix/sysv/linux/sparc/sparc32/mmap64.c: Likewise.

Please check the glibc mailing list archive for those patches.


H.J.