This is the mail archive of the mailing list for the GCC 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]

Re: [RFA:] Fix other/14354: low precision on subnormal single FPnumbers multiplied with fp-bit.c

> Date: Wed, 03 Mar 2004 17:57:18 -0800
> From: Jim Wilson <>

Thank you for the review!  Sorry for continuing:

> Hans-Peter Nilsson wrote:
> >         * config/fp-bit.c (_fpdiv_parts): Do not round when pack_d would
> >         round the same.  When rounding, clear bits that would cause a
> >         second rounding in pack_d.
> >         (_fpmul_parts): Ditto.  Remove #if 0:d code.
> Did you look at gdb/sim/common/sim-fpu.c?

(For the record, that's <toplevel>/sim/common/sim-fpu.c, which
is maintained by the gdb project, i.e. "part of" gdb.)

No.  I neglected to mention that did investigate what happened
for *some* sim targets for the buildable targets that I ran that
got the test-case right when running the test-suite.  I must
have missed mips and frv, because they both use sim-fpu.c.
(Amusing note: ppc uses host arithmetic below a comment saying
HACK, and also has an (quite outdated, uncorrected) fp-bit.c
copy in sim/ppc/dp-bit.c.  Hmm, maybe that made me turn away
from sim/.)

>  This is a heavily modified 
> version of fp-bit.c that has many bugs fixed.  Generally, when fp-bit.c 
> is wrong, I look at sim-fpu.c to see what the proper fix is.  I think 
> the best way to improve fp-bit.c is to replace it with sim-fpu.c.

Why the general confidence in sim-fpu.c over fp-bit.c?  I wonder
why any corrections haven't propagated, given that the GDB and
GCC crowds have a large intersection.  Is there a related
history or something else about it that I don't know about?
Either way, I'd have guessed that the code in GCC received more
maintenance attention than the one in sim.

> Your patch looks like an improvement over current code since it gets a 
> little close to sim-fpu.c, but it appears to be slightly different, and 
> hence I suspect we will still get some edge cases wrong.
> The only good way to test fp-bit.c is to generate lots of FP numbers and 
> perform operations on them, and check to see if the result is correct, 
> but that is a pain to do.

I hope I have done that to a reasonable extent; both by
successfully running the patch through the testsuite that
exposed the bug, and by the ghostscript tests.

> I will approve this, and very strongly suggest that you look at 
> sim-fpu.c in gdb's sim/common directory.

Please excuse my denseness: I don't understand what you here
refer to by "this".  Do you approve the patch as-is, or a patch
adjusted to make that part be more like that in sim-fpu.c or to
something else?

If you refer to a change significantly larger than the context
of the patch, I'd rather import tege's floating-point library.

brgds, H-P

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