This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Arch maintainers: please regenerate libm-test-ulps for 2.19
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: <kkojima at rr dot iij4u dot or dot jp>
- Cc: <libc-alpha at sourceware dot org>
- Date: Sat, 25 Jan 2014 01:47:38 +0000
- Subject: Re: Arch maintainers: please regenerate libm-test-ulps for 2.19
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1401241756580 dot 9799 at digraph dot polyomino dot org dot uk> <20140125 dot 102826 dot 25878266 dot kkojima at rr dot iij4u dot or dot jp>
On Sat, 25 Jan 2014, kkojima@rr.iij4u.or.jp wrote:
> "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> > The following architectures do not appear to have had libm-test-ulps
> > regenerated for 2.19:
> [snip]
> > sh (I also suggest moving the file from sysdeps/sh/sh4/fpu to sysdeps/sh,
> > as ulps for SH4 with FPU should be a superset of those for other
> > variants)
>
> I've committed the patch below.
The errors for fma indicate a (presumably SH-specific) bug (which should
be filed in Bugzilla before investigating it).
Those for float
+Test "fma (0x1.7ff8p+13, 0x1.000002p+0, 0x1.ffffp-24)":
+float: 1
+ifloat: 1
are undoubtedly the easiest to investigate. First make sure that the case
in sysdeps/sh/s_fmaf.c that includes sysdeps/ieee754/dbl-64/s_fmaf.c is
indeed the one being used. Then disassemble fmaf and see if all the
operations are in the right order - nothing's been scheduled across a call
to feholdexcept / fesetround / feupdateenv / fetestexcept. If there's a
scheduling problem, we can work out how to prevent it, otherwise it's
likely to be a problem with one of those <fenv.h> functions.
--
Joseph S. Myers
joseph@codesourcery.com