This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Promote a math test for sNaN handling to the top-level.
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Thomas Schwinge <thomas at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>, <munroesj at us dot ibm dot com>, <rsa at us dot ibm dot com>
- Date: Tue, 5 Mar 2013 23:29:32 +0000
- Subject: Re: [PATCH] Promote a math test for sNaN handling to the top-level.
- References: <1362512203-31849-1-git-send-email-thomas@codesourcery.com>
On Tue, 5 Mar 2013, Thomas Schwinge wrote:
> Tested on x86 and x86_64 GNU/Linux natively, and cross-tested for MIPS32
> O32 GNU/Linux.
>
> * sysdeps/powerpc/fpu/test-powerpc-snan.c: Rename to
> math/test-snan.c.
> * math/test-snan.c: Renamed from
> sysdeps/powerpc/fpu/test-powerpc-snan.c.
> * math/Makefile (tests): Add test-snan.
> * sysdeps/powerpc/fpu/Makefile (libm-tests): Don't add
> test-powerpc-snan.
This test is not portable. init_signaling_nan hard-codes bit-patterns,
including for IBM long double, and those patterns also embed a big-endian
assumption as well as floating-point format assumptions. Thus, it should
not be treated as generic as-is. The sNaNs need initializing portably
instead, using the appropriate GCC built-in functions.
(Because the test never tests any case that *should* raise an exception,
the failure to use the correct bit-patterns doesn't result in it failing.)
--
Joseph S. Myers
joseph@codesourcery.com