Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing

[Richard Sandiford <rdsandiford@googlemail.com>]

"Maciej W. Rozycki" <macro@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  <macro@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