This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |