This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH RFC] <math.h> issignaling
On Mon, Mar 11, 2013 at 01:47:18PM +0100, Thomas Schwinge wrote:
> On Thu, 7 Mar 2013 21:08:09 +0000, "Joseph S. Myers" <firstname.lastname@example.org> 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.
If x86 really has this bug, what is the point in trying to work around
it? The compiler could choose to load the value at almost any time, so
chances are it will already have raised the exception.