(elisp)Numbers

(elisp)Numbers

[Luc Teirlinck]

What do we do with (elisp)Numbers now that integers have 29 bits?  (On
most machines.)  Should all examples in (elisp)Numbers be rewritten
for 29 bits or not?  Note that this would make the examples look
somewhat differently.  Instead of 7 groups of 4 we now would have one
digit "sticking out" to the left.

Sincerely,

Luc.

Re: (elisp)Numbers

[Eli Zaretskii]

> Date: Sat, 4 Oct 2003 10:36:20 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> What do we do with (elisp)Numbers now that integers have 29 bits?  (On
> most machines.)  Should all examples in (elisp)Numbers be rewritten
> for 29 bits or not?

Yes, I think so.

(elisp)Numbers

[Luc Teirlinck]

I read (elisp)Numbers and apart from a small correction to
(elisp)Integer Basics (in the overflow example), which I already
committed, I only have two questions:

1.  In (elisp)Numeric Conversions, is it worth pointing out that not
    only `floor', but also `truncate', `ceiling' and `round' take an
    optional DIVISOR argument?  (elisp)Numeric Conversions makes it
    look like only `floor' does. 

2.  In (elisp)Math Functions, it is said that asin, acos, log, log10
    and sqrt all return NaN values for out-of-range arguments, but, on
    my machine, only `sqrt' does.  The others throw an error, see the
    IELM run below.  Is this machine dependent?

ELISP> (asin 3)
*** Eval error ***  Arithmetic domain error: "asin", 3
ELISP> (acos 3)
*** Eval error ***  Arithmetic domain error: "acos", 3
ELISP> (log -3)
*** Eval error ***  Arithmetic domain error: "log", -3
ELISP> (log10 -3)
*** Eval error ***  Arithmetic domain error: "log10", -3
ELISP> (sqrt -3)
-0.0e+NaN
ELISP> (emacs-version)
"GNU Emacs 21.3.50.1 (i686-pc-linux-gnu, X toolkit)\n of 2003-10-20 on
swt40.swt.com"
ELISP> 

Sincerely,

Luc.

Re: (elisp)Numbers

[Eli Zaretskii]

> Date: Mon, 20 Oct 2003 21:29:16 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> 
> 1.  In (elisp)Numeric Conversions, is it worth pointing out that not
>     only `floor', but also `truncate', `ceiling' and `round' take an
>     optional DIVISOR argument?

IMHO, yes.

> 2.  In (elisp)Math Functions, it is said that asin, acos, log, log10
>     and sqrt all return NaN values for out-of-range arguments, but, on
>     my machine, only `sqrt' does.  The others throw an error, see the
>     IELM run below.  Is this machine dependent?

Yes, see the commentary at the beginning of src/floatfns.c, in
particular the HAVE_MATHERR and the various FLOAT_CHECK_* macros.  The
bottom line is that the details depend on the specific implementation
of handling abnormal arguments by the system libraries.  (Btw, I
expect the bahavior we see today to change over the next years, as C9x
propagates with its new requirements about FP exceptions.)

Re: (elisp)Numbers

[Richard Stallman]

    2.  In (elisp)Math Functions, it is said that asin, acos, log, log10
	and sqrt all return NaN values for out-of-range arguments, but, on
	my machine, only `sqrt' does.  The others throw an error, see the
	IELM run below.

I get the same results.  I figured out why.  I'm using an x86.  Facos
calls acos, but in Fsqrt the call to sqrt gets open-coded using the
fsqrt instruction.  fsqrt doesn't set errno as it is expected to.
Perhaps that is a GCC bug.

I have GCC 2.95.4, which is rather old.  Can anyone else try this
with the latest GCC, so we can see if the bug still exists?

Re: (elisp)Numbers

[Richard Stallman]

      (Btw, I
    expect the bahavior we see today to change over the next years, as C9x
    propagates with its new requirements about FP exceptions.)

I have never seen the C9X spec.  What are these changes
that are relevant to this?

Re: (elisp)Numbers

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     2.  In (elisp)Math Functions, it is said that asin, acos, log, log10
> 	and sqrt all return NaN values for out-of-range arguments, but, on
> 	my machine, only `sqrt' does.  The others throw an error, see the
> 	IELM run below.
>
> I get the same results.  I figured out why.  I'm using an x86.  Facos
> calls acos, but in Fsqrt the call to sqrt gets open-coded using the
> fsqrt instruction.  fsqrt doesn't set errno as it is expected to.
> Perhaps that is a GCC bug.

GCC does not fully support C99 yet.

According to C99 a domain error results in an implementation-defined
value, and if math_errhandling & MATH_ERRNO is non-zero, errno is set
appropriately.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, 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."

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 22 Oct 2003 05:25:37 -0400
> 
> I get the same results.  I figured out why.  I'm using an x86.  Facos
> calls acos, but in Fsqrt the call to sqrt gets open-coded using the
> fsqrt instruction.  fsqrt doesn't set errno as it is expected to.
> Perhaps that is a GCC bug.

I don't think it's a bug at all.  Last time I looked closely at the
code emitted by GCC in such situations, it indeed issues the FSQRT
instruction, but after that carefully examines the appropriate bits in
the x87 status register, and if any of the bits are set that indicate
that a numeric exception has happened, it calls the `sqrt' function
from the library, assuming (quite correctly, IMHO) that the library
code will deal with abnormal results according to whatever ANSI/Posix
requires in the particular environment and platform where you run the
code.

If you say "gcc -S" and look at the code, don't you see the FSQRT
instruction being followed by tests on bits in the FPU status word,
followed by the call to `sqrt' from the library?

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 22 Oct 2003 05:26:02 -0400
> 
> I have never seen the C9X spec.  What are these changes
> that are relevant to this?

ANSI C89 specifically mandated that math library functions should set
errno when they see abnormal arguments; that means implicitly that the
library cannot generate a SIGFPE, because SIGFPE will (by default)
terminate the program, and thus the program will not have any chance
looking at errno.  In practice, this required that most environments
mask the numerical exceptions, to avoid a SIGFPE.

C9x, AFAIU, requires that a numerical exception be raised, as well as
that errno be set.  So it, in effect, requires a machinery to raise a
``quiet exception'', one that doesn't trigger SIGFPE, at least not by
default.  In other words, the new ANSI standard codifies the numerical
exceptions, which means that library implementors will need to modify
the behavior of library functions to comply.  That is why I expect
some changes in this area as the new standard catches.

Re: (elisp)Numbers

[Richard Stallman]

    If you say "gcc -S" and look at the code, don't you see the FSQRT
    instruction being followed by tests on bits in the FPU status word,
    followed by the call to `sqrt' from the library?

i don't see that on the x87 code here.
anyway, it does not signal the exception.
can someone try to debug this?

also, i compile with -O0.  should that really open-code sqrt?

Re: (elisp)Numbers

[Andreas Schwab]

Richard Stallman <rms@gnu.org> writes:

>     If you say "gcc -S" and look at the code, don't you see the FSQRT
>     instruction being followed by tests on bits in the FPU status word,
>     followed by the call to `sqrt' from the library?
>
> i don't see that on the x87 code here.
> anyway, it does not signal the exception.
> can someone try to debug this?
>
> also, i compile with -O0.  should that really open-code sqrt?

Please check that sqrt is not a macro.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, 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."

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 23 Oct 2003 14:38:07 -0400
> 
>     If you say "gcc -S" and look at the code, don't you see the FSQRT
>     instruction being followed by tests on bits in the FPU status word,
>     followed by the call to `sqrt' from the library?
> 
> i don't see that on the x87 code here.

The DJGPP port of GCC 2.95.3 does produce the code I described.
Perhaps on GNU/Linux, the library and/or the kernel somehow do the
equivalent of it, I don't know enough about GCC configuration on that
platform to tell.

> anyway, it does not signal the exception.
> can someone try to debug this?

I'll try if no one else does.

> also, i compile with -O0.  should that really open-code sqrt?

I tried that on fencepost (they also have GCC 2.95.4 there), and it
didn't open-code sqrt under -O0.

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Fri, 24 Oct 2003 10:43:06 +0200
> >
> > also, i compile with -O0.  should that really open-code sqrt?
> 
> Please check that sqrt is not a macro.

Yes, it seems that sqrt is expanded into inline code that always
issues the FSQRT instruction, and doesn't set errno.  However, the
glibc manual seems to say that this should only happen under
"-ffast-math", and at least with GCC 2.95.4 on fencepost I cannot
reproduce this problem, it generates a call to the library function
under "-O0".

Re: (elisp)Numbers

[Eli Zaretskii]

> Date: Fri, 24 Oct 2003 15:38:18 +0200
> From: "Eli Zaretskii" <eliz@elta.co.il>
> 
> > anyway, it does not signal the exception.
> > can someone try to debug this?
> 
> I'll try if no one else does.

As far as I could see, the problem happens because the definition of
the IN_FLOAT macro on GNU/Linux relies on sqrt to set errno, but the
expansion of the sqrt macro fails to do so.  I stepped with GDB thru
the code generated for the line in Fsqrt that says

   IN_FLOAT (d = sqrt (d), "sqrt", arg);

and the value of errno stays zero after the code computes the square
root.

So this sounds like a glibc bug, perhaps combined with a GCC bug: the
expansion of the sqrt macro doesn't set errno for abnormal arguments.
(I'm guessing that similar things happen for many other functions
from floatfns.c.)

Re: (elisp)Numbers

[Eli Zaretskii]

> Date: Fri, 24 Oct 2003 15:50:41 +0200
> From: "Eli Zaretskii" <eliz@elta.co.il>
> 
> > From: Andreas Schwab <schwab@suse.de>
> > Date: Fri, 24 Oct 2003 10:43:06 +0200
> > >
> > > also, i compile with -O0.  should that really open-code sqrt?
> > 
> > Please check that sqrt is not a macro.
> 
> Yes, it seems that sqrt is expanded into inline code that always
> issues the FSQRT instruction, and doesn't set errno.

Here's the code I see with "gcc -E -O2" on fencepost (I reformatted it
for better readability):

    extern __inline double sqrt ( double __x) 
    { 
      register double __result;
      __asm __volatile__ ( "fsqrt" : "=t" (__result) : "0" (__x) );
       return __result; 
    }

As you see, it never sets errno.

Re: (elisp)Numbers

[Richard Stallman]

    Here's the code I see with "gcc -E -O2" on fencepost (I reformatted it
    for better readability):

	extern __inline double sqrt ( double __x) 
	{ 
	  register double __result;
	  __asm __volatile__ ( "fsqrt" : "=t" (__result) : "0" (__x) );
	   return __result; 
	}

1. where does this code come from?  which file in which package?

2. i see that my CFLAGS setting to turn off inlining got lost
when i reran configure.  so i put that back in and recompiled,
and it went away.

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 25 Oct 2003 18:26:38 -0400
> 
>     Here's the code I see with "gcc -E -O2" on fencepost (I reformatted it
>     for better readability):
> 
> 	extern __inline double sqrt ( double __x) 
> 	{ 
> 	  register double __result;
> 	  __asm __volatile__ ( "fsqrt" : "=t" (__result) : "0" (__x) );
> 	   return __result; 
> 	}
> 
> 1. where does this code come from?  which file in which package?

This is part of cpp's output when I run on floatfns.c the same
command as when it is compiled into floatfns.o, but with -c replaced
with -E.  For the build on fencepost, this is the command I ran:

  gcc -E -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -I. -I/home/e/eliz/emacs/src -D_BSD_SOURCE -O2 floatfns.c | less -ci

If you omit -O2, the inline expansion of `sqrt' doesn't appear in the
output, so the library function is called.

The expansion itself seems to come from
/usr/include/bits/mathinline.h, which is part of glibc, since
immediately before the above snippet, I see this line:

   # 438 "/usr/include/bits/mathinline.h" 3

mathinlines.h has this near line 438:

   __inline_mathopNP (sqrt, "fsqrt")

which, after a series of macro expansions, eventually expands into
the above inline definition of `sqrt'.

Similar things happen with other math functions.  It sounds like
under -O2 no math function ever sets errno.

> 2. i see that my CFLAGS setting to turn off inlining got lost
> when i reran configure.  so i put that back in and recompiled,
> and it went away.

What went away?  You mean that Emacs did throw a domain error when
floatfns.c was compiled without optimizations?

Anyway, we do want floatfns.c to be compiled with optimization and
still DTRT, right?

Re: (elisp)Numbers

[Richard Stallman]

    > 2. i see that my CFLAGS setting to turn off inlining got lost
    > when i reran configure.  so i put that back in and recompiled,
    > and it went away.

    What went away?

the open-coded sqrt insn went away.  it calls a library fn instead.

    Anyway, we do want floatfns.c to be compiled with optimization and
    still DTRT, right?

right.  what libc version are you using?  that needs to be in glibc
bug report.

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Mon, 27 Oct 2003 02:02:22 -0500
> 
> what libc version are you using?

I made the tests on fencepost, where /usr/include/features.h defines:

  #define __GLIBC__       2
  #define __GLIBC_MINOR__ 2

So it looks like the glibc version is 2.2.

Re: (elisp)Numbers

[Andreas Schwab]

"Eli Zaretskii" <eliz@elta.co.il> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Date: Mon, 27 Oct 2003 02:02:22 -0500
>> 
>> what libc version are you using?
>
> I made the tests on fencepost, where /usr/include/features.h defines:
>
>   #define __GLIBC__       2
>   #define __GLIBC_MINOR__ 2
>
> So it looks like the glibc version is 2.2.

In glibc 2.3 sqrt is only inlined with -ffast-math.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, 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."

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Andreas Schwab <schwab@suse.de>
> Date: Mon, 27 Oct 2003 22:46:19 +0100
> 
> In glibc 2.3 sqrt is only inlined with -ffast-math.

So perhaps we should add something to configure to detect this and
use -O0 for compiling floatfns.c if necessary.

Re: (elisp)Numbers

[Lars Brinkhoff]

Eli Zaretskii <eliz@elta.co.il> writes:
> > From: Andreas Schwab <schwab@suse.de>
> > In glibc 2.3 sqrt is only inlined with -ffast-math.
> So perhaps we should add something to configure to detect this and
> use -O0 for compiling floatfns.c if necessary.

Perhaps -fno-fast-math first.

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/

Re: (elisp)Numbers

[Eli Zaretskii]

> From: Lars Brinkhoff <lars@nocrew.org>
> Date: 28 Oct 2003 07:40:54 +0100
> 
> Eli Zaretskii <eliz@elta.co.il> writes:
> > So perhaps we should add something to configure to detect this and
> > use -O0 for compiling floatfns.c if necessary.
> 
> Perhaps -fno-fast-math first.

I tried this; it doesn't work: sqrt is still expanded inline into
code that never calls the library function nor sets errno.

Re: (elisp)Numbers

[Richard Stallman]

    In glibc 2.3 sqrt is only inlined with -ffast-math.

If they already fixed the bug, I guess I may as well skip reporting it. 
Thanks to both of you.