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