This is the mail archive of the
mailing list for the GCC project.
Re: [RFA:] Fix other/14354: low precision on subnormal single FPnumbers multiplied with fp-bit.c
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: wilson at specifixinc dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 4 Mar 2004 22:57:09 +0100
- Subject: 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 <email@example.com>
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
> 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
If you refer to a change significantly larger than the context
of the patch, I'd rather import tege's floating-point library.