Re: [PATCH RFC] <math.h> issignaling

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Wed, 6 Mar 2013 18:13:54 +0000, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Wed, 6 Mar 2013, Thomas Schwinge wrote:
> 
> > Currently I'm providing a __issignalingl symbol (aliased to
> > __issignaling) if NO_LONG_DOUBLE is defined.  The <math.h> issignaling
> > macro definition on the other hand adds long double support based on
> > __NO_LONG_DOUBLE_MATH being defined.  I don't completely understand yet
> > what exactly each of NO_LONG_DOUBLE, __NO_LONG_DOUBLE_MATH, and then
> > __LONG_DOUBLE_MATH_OPTIONAL are to achieve, and which I have to care for;
> > also whether I need to do anything with sysdeps/ieee754/ldbl-opt and
> > sysdeps/ieee754/ldbl-64-128 (don't think so)?

So, as I found, NO_LONG_DOUBLE is defined by the glibc build system
(math/Makefile), depending on whether the host architecture instructs by
sysdeps/*/Makefile defining Âlong-double-fcts = yes that it has a
distinct long double type, and if not, this controls that FUNCl aliases
are created for some FUNC.  __NO_LONG_DOUBLE_MATH on the other hand comes
From generic or sysdeps bits/mathdef.h or bits/wordsize.h files, and
(primarily) controls whether the FUNCl symbols will be used (from header
files, for example).  ports/sysdeps/alpha/bits/mathdef.h says that
Â[t]his file describes properties of the compiler, not the machine; it
should not be part of libcÂ.

> I don't think an __issignalingl alias should be provided.  If double and 
> long double have the same representation, the header macro should never 
> call __issignalingl.

Indeed; changed.


> > On 32-bit x86, the __issignalingf and __issignaling functions already
> > "fail" at the call site:
> > 
> >      804a130:       d9 05 18 e1 04 08       flds   0x804e118
> >      804a136:       d9 1c 24                fstps  (%esp)
> >      804a139:       e8 d2 eb ff ff          call   8048d10 <__issignalingf@plt>
> 
> Does this depend on compiler options (you don't say what specific code 
> shows this problem)?  A test I did of passing a float variable to a 
> function used integer load/store to move it to the stack, not 
> floating-point.

    $ cat < ../snan.c
    extern int __issignalingf(float);
    
    int main(void)
    {
      static VOLATILE float snan_var = __builtin_nansf("");
    
      return __issignalingf(snan_var);
    }

volatile, -O0 vs. -O1:

    $ diff -u <(gcc -Wall -S -o - ../snan.c -DVOLATILE=volatile -O0) <(gcc -Wall -S -o - ../snan.c -DVOLATILE=volatile -O1)
    --- /dev/fd/63  2013-03-07 11:43:29.789044897 +0100
    +++ /dev/fd/62  2013-03-07 11:43:29.789044897 +0100
    @@ -12,8 +12,8 @@
            .cfi_def_cfa_register 5
            andl    $-16, %esp
            subl    $16, %esp
    -       movl    snan_var.1360, %eax
    -       movl    %eax, (%esp)
    +       flds    snan_var.1360
    +       fstps   (%esp)
            call    __issignalingf
            leave
            .cfi_restore 5

-O1, volatile vs. not volatile:

    $ diff -u <(gcc -Wall -S -o - ../snan.c -DVOLATILE=volatile -O1) <(gcc -Wall -S -o - ../snan.c -DVOLATILE= -O1)
    --- /dev/fd/63  2013-03-07 11:43:52.202459686 +0100
    +++ /dev/fd/62  2013-03-07 11:43:52.202459686 +0100
    @@ -12,8 +12,7 @@
            .cfi_def_cfa_register 5
            andl    $-16, %esp
            subl    $16, %esp
    -       flds    snan_var.1360
    -       fstps   (%esp)
    +       movl    $0x7fa00000, (%esp)
            call    __issignalingf
            leave
            .cfi_restore 5
    @@ -22,11 +21,5 @@
            .cfi_endproc
     .LFE0:
            .size   main, .-main
    -       .data
    -       .align 4
    -       .type   snan_var.1360, @object
    -       .size   snan_var.1360, 4
    -snan_var.1360:
    -       .long   2141192192
            .ident  "GCC: (Debian 4.7.2-5) 4.7.2"
            .section        .note.GNU-stack,"",@progbits

> > For float and double (but not long double), per the x86 ISA, this will
> > load the sNaN variable (0x804e118), but then turn it into a qNaN and
> > raise the INVALID exception.  (Thus, the __issignalingf function will
> > never be able to detect a sNaN.)  I hope to get around this by adding
> > always_inline definitions for the __issignaling functions to the
> > respective mathinline.h files.  (But what about someone using <math.h>
> 
> Or the macro could use a union to pass the value to a function defined to 
> take an integer value, if that helps.

To avoid any such issues, that may indeed be the more workable solution,
so I'll give that a try, thanks.


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature