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]

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


On Fri, 15 Mar 2013, Thomas Schwinge wrote:

> 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.)

If that's how you wish to do it.  There's no actual XFAIL mechanism here, 
so it would be lots of #if conditionals in libm-test.inc (based on a 
define from a sysdeps header file, I suppose), though.  (The uses of 
issignaling to verify that a function return value is a quiet NaN 
shouldn't need conditioning, though they might not work properly on 32-bit 
x86.  And those would cover one purpose of this series - being able to 
verify that functions such as sqrtl return the right sort of NaN on MIPS, 
where presently they don't.)

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

To avoid errors about conflicting types you may be able to use asm 
("asm-name") on various declarations, to give functions different names in 
the compiler output from those that they have at C level.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]