This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/13304] fma, fmaf, fmal produce wrong results
- From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Thu, 22 Nov 2012 17:39:07 +0000
- Subject: [Bug math/13304] fma, fmaf, fmal produce wrong results
- Auto-submitted: auto-generated
- References: <bug-13304-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13304
Joseph Myers <jsm28 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target|x86_64-suse-linux-gnu |
Host|x86_64-suse-linux-gnu |
Build|x86_64-suse-linux-gnu |
--- Comment #38 from Joseph Myers <jsm28 at gcc dot gnu.org> 2012-11-22 17:39:07 UTC ---
FWIW, the ldbl-128ibm version of fmal, which I think would better be replaced
by a generic version such as that discussed here (which would also be useful
for platforms without FE_INEXACT / FE_TOWARDZERO), not only is incorrect in
that it doesn't provide a fused operation, but also appears to produce results
that are actually invalid long double values, when in directed rounding modes,
e.g.:
Failure: Test: fma_towardzero (max_value, max_value, min_value) == max_value
Result:
is: 1.79769313486231590772e+308 0x1.ffffffffffffffffffffp+1023
should be: 1.79769313486231580793e+308 0x1.fffffffffffff7ffffffp+1023
difference: 1.79769313486231550856e+308 0x1.ffffffffffffe0000000p+1023
ulp : 81129638414606663681390495662080.0000
max.ulp : 0.0000
(Such edges cases for ldbl-128ibm might end up as separate issues, but it
probably doesn't make sense to file such separate issues for them until fmal
for ldbl-128ibm is basically right, most likely through use of a generic
implementation.)
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.