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

On Wed, 7 Aug 2013, Richard Sandiford wrote:

> > When I run two of your new tests in gcc.target/mips (nan-legacy.c and
> > nans-legacy.c), they are failing because my GCC is putting out
> >
> > 	.word	4294967295
> >
> > instead of 
> >
> > 	.word	-1
> >
> > like the test is expecting.
> >
> > I believe they are equivalent (0xffffffff) but I am not sure what it
> > is about my targets (mips-mti-elf and mips-mti-linux-gnu) that would
> > make this different from yours.  Should the tests be modified to allow
> > either output?
> 
> Maciej, have you had chance to look at this yet?

 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.

 This has passed mips-linux-gnu regression testing on a 32-bit host, but I 
can't regression-test a 64-bit host easily -- Steve, can you please verify 
that this change indeed works for you?  Richard, OK to apply assuming that 
it does?

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.

  Maciej

gcc-mips-nan2008-test-fix.diff

On Tue, 2013-08-13 at 14:28 +0100, Maciej W. Rozycki wrote:

>  This has passed mips-linux-gnu regression testing on a 32-bit host, but I 
> can't regression-test a 64-bit host easily -- Steve, can you please verify 
> that this change indeed works for you?  Richard, OK to apply assuming that 
> it does?

Maciej, the patch does work for me.

Steve Ellcey
sellcey@mips.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

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