This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH RFC] <math.h> issignaling
On Thu, 7 Mar 2013, Thomas Schwinge wrote:
> Now, I have no idea if this version of GCC that I'm using for testing is
> actually meant to follow that specification, but not matter what, this is
> still unusable for our glibc purposes.
glibc tests are not about how negation works for sNaN. You should have a
variable storing a negative sNaN (statically initialized to such) and use
that to test negative sNaN arguments to functions.
The GCC signaling NaN support is based on a very old document, N965, which
was not, as far as I can tell, used as a basis in any way for the work in
DTS 18661-1.
> 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.
DTS 18661-1 says "[3] Whether C assignment (6.5.16) (and conversion as if
by assignment) to the same format is an IEC 60559 convertFormat or copy
operation is implementation-defined, even if <fenv.h> defines the macro
FE_SNANS_ALWAYS_SIGNAL (F.2.1).". The correct answer for 32-bit x86 may
depend on whether the ABI actually requires the value to be extended into
a floating-point register (e.g. for function return) or not, but it's not
particularly clear that there is a bug here.
--
Joseph S. Myers
joseph@codesourcery.com