This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

"Maciej W. Rozycki" <> 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  <>
> 	gcc/testsuite/
> 	* Accept 4294967295 as an 
> 	alternative to -1.
> 	* Likewise.

OK, thanks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]