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: Jim Wilson <wilson at specifixinc dot com>
- To: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 04 Mar 2004 15:13:22 -0800
- Subject: Re: [RFA:] Fix other/14354: low precision on subnormal single FPnumbers multiplied with fp-bit.c
- References: <200403042157.i24Lv9fZ000302@ignucius.se.axis.com>
On Thu, 2004-03-04 at 13:57, Hans-Peter Nilsson wrote:
> Why the general confidence in sim-fpu.c over fp-bit.c?
The last few bug fix patches I have looked at for fp-bit.c have been for
problems that were already fixed in sim-fpu.c. This one included.
I think sim-fpu.c has gotten more testing than fp-bit.c. fp-bit.c is
only used for soft-float targets, and people using soft-float targets
generally don't do a lot of FP because it is too slow. sim-fpu.c
however is used for hard-float targets, and people with hard-float
targets expect FP to work correctly, and will notice when it doesn't.
> why any corrections haven't propagated, given that the GDB and
> GCC crowds have a large intersection.
I don't think there is any particular history. I think the main problem
is that most gcc people don't know about the gdb sim-fpu.c, and most gdb
people don't know about gcc fp-bit.c. Or maybe people know and keep
forgetting about it.
There are some interface differences between sim-fpu.c and fp-bit.c
because they are serving slightly different purposes. So they can't be
shared as is. It might be possible to abstract out the core routines
from the different interfaces though.
> 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?
I am approving the patch as is. I am also pointing out that more work
could be done here if someone cared.
> If you refer to a change significantly larger than the context
> of the patch, I'd rather import tege's floating-point library.
Yes, Torbjorn's soft-FP library is also a good alternative, and probably
even better than sim-fpu.c.
Also, now that the tree-ssa Fortran95 compiler requires GMP, we could
consider a soft-FP library implementation that directly uses GMP.
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com