* fma ulps
[not found] <20120530233749.16824.qmail@sourceware.org>
@ 2012-05-30 23:51 ` Joseph S. Myers
2012-05-31 0:25 ` Chris Metcalf
0 siblings, 1 reply; 3+ messages in thread
From: Joseph S. Myers @ 2012-05-30 23:51 UTC (permalink / raw)
To: rth; +Cc: libc-ports
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: fma ulps
2012-05-30 23:51 ` fma ulps Joseph S. Myers
@ 2012-05-31 0:25 ` Chris Metcalf
2012-05-31 0:30 ` Joseph S. Myers
0 siblings, 1 reply; 3+ messages in thread
From: Chris Metcalf @ 2012-05-31 0:25 UTC (permalink / raw)
To: Joseph S. Myers; +Cc: rth, libc-ports
On 5/30/2012 7:51 PM, Joseph S. Myers wrote:
> 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.
Just to confirm, I did record some 1-ulp results for tile, but only because
the rounding-mode support doesn't exist. Presumably in that case it's
still better to list ulps than to let the test fail?
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: fma ulps
2012-05-31 0:25 ` Chris Metcalf
@ 2012-05-31 0:30 ` Joseph S. Myers
0 siblings, 0 replies; 3+ messages in thread
From: Joseph S. Myers @ 2012-05-31 0:30 UTC (permalink / raw)
To: Chris Metcalf; +Cc: rth, libc-ports
On Wed, 30 May 2012, Chris Metcalf wrote:
> > fma isn't meant to have ulps.
>
> Just to confirm, I did record some 1-ulp results for tile, but only because
> the rounding-mode support doesn't exist. Presumably in that case it's
> still better to list ulps than to let the test fail?
Given that you know the cause, and that there is an open bug for the
issue, yes. But I don't think it's a good idea to add ulps for such
functions with fully-defined results without at least having the open bug
- and in the alpha case, there is a plausible cause that may not be hard
to fix (needing to build s_fma.c, s_fmaf.c and s_fmal.c with
-mieee-with-inexact).
--
Joseph S. Myers
joseph@codesourcery.com
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-05-31 0:30 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20120530233749.16824.qmail@sourceware.org>
2012-05-30 23:51 ` fma ulps Joseph S. Myers
2012-05-31 0:25 ` Chris Metcalf
2012-05-31 0:30 ` Joseph S. Myers
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).