This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
fma ulps
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: rth at twiddle dot net
- Cc: libc-ports at sourceware dot org
- Date: Wed, 30 May 2012 23:51:16 +0000 (UTC)
- Subject: fma ulps
- References: <20120530233749.16824.qmail@sourceware.org>
On Wed, 30 May 2012, rth@sourceware.org wrote:
> +# fma
> +Test "fma (-0x1.19cab66d73e17p-959, 0x1.c7108a8c5ff51p-107, -0x0.80b0ad65d9b64p-1022) == -0x0.80b0ad65d9d59p-1022":
> +double: 1
> +idouble: 1
> +Test "fma (0x1.0000002p+0, 0x1.ffffffcp-1, -0x1p-300) == 0x1.fffffffffffffp-1":
> +double: 1
> +idouble: 1
> +Test "fma (0x1.153d650bb9f06p-907, 0x1.2d01230d48407p-125, -0x0.b278d5acfc3cp-1022) == -0x0.b22757123bbe9p-1022":
> +double: 1
> +idouble: 1
> +Test "fma (0x1.4000004p-967, 0x1p-106, 0x0.000001p-1022) == 0x0.0000010000003p-1022":
> +double: 1
> +idouble: 1
fma isn't meant to have ulps. You previously mentioned that special
options are needed to get "inexact" exceptions on alpha, and the fma code
relies on testing those exceptions to get correct results, so maybe you
need to make appropriate arrangements for it (for all floating-point
types) to be compiled with the right options to get such exceptions?
(I cut out fma ulps from my ARM results, pending testing on hardware to
see if they were a QEMU bug or something needing further investigation.)
--
Joseph S. Myers
joseph@codesourcery.com