"Maciej W. Rozycki" <ma...@codesourcery.com> writes: > 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. I can't argue with the path of least resistance though. > 2013-08-13 Maciej W. Rozycki <ma...@codesourcery.com> > > gcc/testsuite/ > * gcc.target/mips/nan-legacy.c: Accept 4294967295 as an > alternative to -1. > * gcc.target/mips/nans-legacy.c: Likewise. OK, thanks. Richard
