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: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rainer Orth <ro at CeBiTec dot Uni-Bielefeld dot DE>
- Cc: gcc-patches at gcc dot gnu dot org, Paolo Bonzini <bonzini at gnu dot org>, Ian Lance Taylor <iant at google dot com>, trevor_smigiel at playstation dot sony dot com, dje dot gcc at gmail dot com, uweigand at de dot ibm dot com
- Date: Wed, 3 Aug 2011 14:33:07 +0000 (UTC)
- Subject: Re: CFT: [build] Move fp-bit support to toplevel libgcc
- References: <yddbowzv35g.fsf@manam.CeBiTec.Uni-Bielefeld.DE> <Pine.LNX.4.64.1107211550510.11368@digraph.polyomino.org.uk> <yddwreumwun.fsf@manam.CeBiTec.Uni-Bielefeld.DE>
On Wed, 3 Aug 2011, Rainer Orth wrote:
> * Even worse, there are a couple of formats/targets that do use
> fp-bit.c, don't yet define QUIET_NAN_NEGATED, but have qnan_msb_set =
> false:
>
> qnan_msb_set uses fp-bit
>
> mips_single_format false x
> spu_single_format false x
> mips_double_format false x
> mips_extended_format false x
> mips_quad_format false x
> vax_f_format false 00
> vax_d_format false 00
> vax_g_format false 00
> arm_half_format false ?
>
> So such a change would mean a change of behavior for spu and arm
> targets.
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?
arm_half_format is another no-NaN format, and fp-bit does not provide any
operations for it (it's a storage format only, not an arithmetic format,
and conversions are provided by config/arm/fp16.c). So there should be no
behavior change for ARM at all (only the definitions for the modes used by
fp-bit are relevant, and HFmode isn't one of those).
But, yes, any change to avoid defining QUIET_NAN_NEGATED specially would
best be kept separate.
--
Joseph S. Myers
joseph@codesourcery.com