This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: CFT: [build] Move fp-bit support to toplevel libgcc
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: joseph at codesourcery dot com (Joseph S. Myers)
- Cc: ro at CeBiTec dot Uni-Bielefeld dot DE (Rainer Orth), gcc-patches at gcc dot gnu dot org, bonzini at gnu dot org (Paolo Bonzini), iant at google dot com (Ian Lance Taylor), trevor_smigiel at playstation dot sony dot com, dje dot gcc at gmail dot com
- Date: Thu, 4 Aug 2011 00:47:21 +0200 (CEST)
- Subject: Re: CFT: [build] Move fp-bit support to toplevel libgcc
Joseph S. Myers wrote:
> The SPU format doesn't support NaNs, so the value of this field isn't
> particularly meaningful for SPU. I'm not clear why SPU is actually using
> fp-bit; what functions from fp-bit will actually end up getting used by
> code built for SPU, and how close does fp-bit get to the required
> semantics?
The only routines that should be used at this point are __unorddf2 and
__fixdfsi, both DFmode routines. In past versions of the compiler, I
think a couple of additional DFmode routines might have been called
(__divdf2 and possibly some additional comparison routines), so those
ought to remain in libgcc for compatibility reasons. Note that DFmode
on the SPU is close enough to IEEE that the fp-bit routines ought to
be fine for this.
As far as I can tell, we never actually called any SFmode fp-bit routines
(and those would indeed have not really been appropriate). Not sure why
those are getting built ... that's probably just for historical reasons.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com