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 jos...@codesourcery.com
