This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug ports/2749] powerpc32 does not build --without-fp
- From: "joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: 15 Sep 2006 16:25:51 -0000
- Subject: [Bug ports/2749] powerpc32 does not build --without-fp
- References: <20060609223502.2749.sjmunroe@us.ibm.com>
- Reply-to: sourceware-bugzilla at sourceware dot org
------- Additional Comments From joseph at codesourcery dot com 2006-09-15 16:25 -------
Subject: Re: powerpc32 does not build --without-fp
On Fri, 15 Sep 2006, sjmunroe at us dot ibm dot com wrote:
> ------- Additional Comments From sjmunroe at us dot ibm dot com 2006-09-15 15:11 -------
> Created an attachment (id=1298)
--> (http://sourceware.org/bugzilla/attachment.cgi?id=1298&action=view)
> --> (http://sourceware.org/bugzilla/attachment.cgi?id=1298&action=view)
> Updated gcc-4.2 patch with fmsub soft-fp implement
>
> This patch implements updated darwin-ldouble.c to add a soft-fp implementation
> of fmsub plus fixes to the FP_SUB_Q support.
Note that the soft-fp fix must be accepted for glibc mainline before it
can go in libgcc's copy, as per FSF policies. It looks OK to me but I
have no approval rights for glibc's master copy, only for the GCC copy
(which effectively means for the build infrastructure integration, i.e.
the one file t-softfp).
For the fmsub implementation, you do FP_PACK_SEMIRAW_Q between the
subtraction and the truncation. This is not correct since it can lead to
double rounding (first the value is rounded to a quad value exactly half
way between two double values, then it gets rounded to a double value that
wasn't the closest to the infinite-precision result). The truncation
needs to be done on the output of the subtraction with sticky bits still
in place, not on the rounded result.
I think the bulk of the fmsub implementation should go in a macro in
op-common.h, that could be used to implement the standard fma and fmaf
library functions. It would need to take fs and wc for both the type in
question and the double width type, and arguments for the three inputs and
the result, and for whether it's to calculate a*b+c or a*b-c. Maybe also
for the type of the long double temporaries you use, but I hope that you
can avoid the explicit packing and unpacking into quad representation.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=2749
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.