On Tue, 13 Aug 2013, Richard Sandiford wrote: > > I've had a look now and that is related to the width of `long' on the > > host -- encode_ieee_double returns its output 32-bit bit patterns in a > > buffer of signed longs. The arithmetic value of these patterns therefore > > depends on whether the width of `long' is 32 bits or wider. > > > > Here, in the case of nan-legacy.c, we have: > > > > image_hi <- 0x7ff7ffff > > image_lo <- 0xffffffff > > > > so the returned pair of long values will be: > > > > 2146959359, -1 > > > > on a host where the width of `long' is 32 bits and: > > > > 2146959359, 4294967295 > > > > on a host where the width of `long' is 64 bits. Then when supplied as the > > argument to the assembly-language .word pseudo-op, the two sets of values > > produce the same bit patterns in the object file produced. > > > > It's not clear to me if this dependency on the width of `long' is a bug > > or feature, but a path-of-least-resistance fix is as follows. > > IMO a bug. If we're sure 32 bits is enough then we should use "int". > If we're not sure we should use HOST_WIDE_INT. The only thing using > "long" is going to do is create this kind of weird host dependence.
Since encode_ieee_double will always return 32-bit chunks I think these days this should really use explicit `int32_t' rather than `long' or trying to guess what `int' or HOST_WIDE_INT might be. The type can be easily autoconf'ed if missing on pre-C99 hosts. Of course all the real.c handlers would have to be reviewed and adjusted accordingly, as would the callers, e.g. assemble_real in varasm.c which is where the buffer in this particular case comes from (`data'). > > gcc/testsuite/ > > * gcc.target/mips/nan-legacy.c: Accept 4294967295 as an > > alternative to -1. > > * gcc.target/mips/nans-legacy.c: Likewise. > > OK, thanks. Thanks for review, applied. Steve, thanks for verifying. Maciej
