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

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Mon, 11 Mar 2013 10:01:27 -0400, Rich Felker <dalias@aerifal.cx> wrote:
> 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" <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.
> 
> 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.

Joseph can probably comment on this more sensibly than I can, but as I
understand the recent draft documents, the idea is that a sNaN value can
be expected to be loaded if and only if it is stored in a static (or
thread-local) variable, and this is the (only) case we're trying to make
work here.  For example, fpclassify(x) must not raise an INVALID
exception if x is a static variable containing a sNaN value.

But on 32-bit x86, fpclassify(x) will raise an INVALID exception, as the
sNaN value (depending on optimization level and/on volatile declaration
of x) is loaded (for a float x) by means of the flds instruction (load
32-bit float from memory), which will raise an INVALID exception and turn
the sNaN into a qNaN.  If on the other hand, that value were loaded using
a movl, things would work as expected, which is what the "integer calling
conventions" are meant to achieve.


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature