[PATCH] Fix remainder calculating bug in single floating pointdivision
Yu.Liu at freescale.com
Thu Jan 10 02:38:19 EST 2008
> -----Original Message-----
> From: linuxppc-dev-bounces+b13201=freescale.com at ozlabs.org
> [mailto:linuxppc-dev-bounces+b13201=freescale.com at ozlabs.org]
> On Behalf Of Kumar Gala
> Sent: Tuesday, January 08, 2008 2:20 PM
> To: Dan Malek
> Cc: Liu Yu; linuxppc-dev at ozlabs.org
> Subject: Re: [PATCH] Fix remainder calculating bug in single
> floating pointdivision
> On Jan 6, 2008, at 2:44 PM, Dan Malek wrote:
> > On Jan 6, 2008, at 12:07 PM, Benjamin Herrenschmidt wrote:
> >> It's nice to see somebody digging in that scary math emu stuff. If
> >> you could also get rid of the warnings, it would be perfect :-)
> > Yes, it is :-) I didn't think it would have a life beyond MPC8xx.
> >> .... that this code was lifted from
> >> somewhere else (glibc ? gcc soft-float ?),
> > It seems like a lifetime ago.... I copied the framework
> from Sparc,
> > and the internals from gcc soft-float. I didn't change any of the
> > internal emulation functions (hence, some of the warnings),
> just the
> > calling interface.
> > While it's convenient, I still don't think kernel float emulation
> > should be a solution. The tools should generate soft-float for the
> > applications and libraries.
> If we think this is really true, we could move to using include/math-
> emu/* instead of the files in powerpc/math-emu.
Why it's better to move to using include/math-emu.
I found they have similar framework, is powerpc/math-emu evolved from
> The problem I had was when I tried to recreate the history of
> the code in powerpc/math-emu and how it doesn't really match
> the glibc code base. There are some differences and I wasn't
> sure if they were do to trying to match PPC HW at a bit level or not.
> I was hoping that the work Liu Yu would get as a bit of a
> testsuite to see if there was any harm in moving over to
> - k
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
More information about the Linuxppc-dev