[PATCH RFC] <math.h> issignaling
Thomas Schwinge
thomas@codesourcery.com
Mon Mar 11 12:47:00 GMT 2013
Hi!
On Thu, 7 Mar 2013 21:08:09 +0000, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Thu, 7 Mar 2013, Thomas Schwinge wrote:
> > Should I gather additional data what happens for other architectures
> > using the "float calling convention"? And, if they're generally fine,
> > should we just XFAIL (or disable) the faulty tests for 32-bit x86 until
> > we can rely on versions of GCC that have this issue fixed for building
> > and testing glibc?
>
> I advise putting the relevant definitions in a bits/ header that can have
> an x86-specific version that uses ints rather than floats for the
> arguments. I expect it to be a peculiarity of 32-bit x86 (and maybe old
> m68k) that loading an sNaN can raise an exception.
Meh, I first overlooked this "detail": the same problem also applies to
any other function that is not supposed to raise a INVALID exception for
a sNaN input, and/or has to act differently for qNaN vs. sNaN inputs,
such as fpclassify and all is* functions. So, yes, I'll try to cook up a
general mechanism for changing the affected (and thusly annotated)
functions' signature to the int calling convention (ABI change, so will
need new symbol versions), and then at the call site already convert from
float to int calling conventions using a union.
$ cat < ../fpclassify_snan.c
#include <math.h>
int main(void)
{
static VOLATILE float snan_var = __builtin_nansf("");
return fpclassify(snan_var) == FP_NAN;
}
$ gcc -m32 -Wall -S -o - ../fpclassify_snan.c -DVOLATILE=volatile -O1
[...]
flds snan_var.2531
fstps (%esp)
call __fpclassifyf
[...]
.type snan_var.2531, @object
.size snan_var.2531, 4
snan_var.2531:
.long 2141192192
.ident "GCC: (Debian 4.7.2-5) 4.7.2"
.section .note.GNU-stack,"",@progbits
Grüße,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20130311/8dd8ec31/attachment.sig>
More information about the Libc-alpha
mailing list