This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

fma ulps


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]