[PATCH RFC] <math.h> issignaling

[Thomas Schwinge]

Hi!

On Mon, 11 Mar 2013 14:53:16 +0000, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Mon, 11 Mar 2013, Thomas Schwinge wrote:
> 
> > 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.
> 
> I don't see why it should be an ABI change on 32-bit x86, when all 
> relevant argument types (float / int / double / long long) are passed on 
> the stack.

Right, of course.

> One thing also to check is that the code showing the problems still shows 
> them when built with -fsignaling-nans.  I don't expect that option to 
> help, but it's logically correct to use it in sNaN testing.

In my testing, specifying that flag doesn't make a difference.  But --
especially as implementing these integer calling conventions get uglier
and uglier the farther I get with it -- could we instead of the
following?  Instead of intruducing these integer calling conventions, fix
this issue in GCC (I can't comment on the complexity of this task,
though), and declare that any unfixed GCC version is not required to do
the right thing in glibc with respect to sNaNs?  (And then XFAIL the
respective tests for 32-bit x86 until we can depend on such GCC
versions.)

Or perhaps I'm implementing the integer calling conventions differently
From how you meant it to be done -- did you already have a specific plan
about the implementation?

So far, I have now changed (depending on a #define) that functions such
as __isinff have a u_int32_t argument instead of a float one, but that is
now falling over the weak_alias (__isinff, isinff), where isinff remains
declared with a float argument, and GCC stops with an »error: conflicting
types for 'isinff'«.  Of course, I could avoid type checking (as we know
that __isinff(u_int32_t) has the same ABI as isinff(float) has), probably
by declaring the weak alias at the assembly language level where there is
no such type checking, but that's what I mean with uglier and uglier.


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/20130315/7a366685/attachment.sig>