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 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
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] |