Message ID | alpine.DEB.1.10.1308130002260.8514@tp.orcam.me.uk |
---|---|
State | Accepted |
Headers | show |
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
Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nan-legacy.c =================================================================== --- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/nan-legacy.c 2013-08-13 14:18:50.008738612 +0100 +++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nan-legacy.c 2013-08-13 14:22:49.568772451 +0100 @@ -4,4 +4,4 @@ double d = __builtin_nan (""); /* { dg-final { scan-assembler "\t\\.nan\tlegacy\n" } } */ -/* { dg-final { scan-assembler "\t\\.word\t2146959359\n\t\\.word\t-1\n" } } */ +/* { dg-final { scan-assembler "\t\\.word\t2146959359\n\t\\.word\t(?:-1|4294967295)\n" } } */ Index: gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nans-legacy.c =================================================================== --- gcc-fsf-trunk-quilt.orig/gcc/testsuite/gcc.target/mips/nans-legacy.c 2013-08-13 14:18:50.008738612 +0100 +++ gcc-fsf-trunk-quilt/gcc/testsuite/gcc.target/mips/nans-legacy.c 2013-08-13 14:22:49.568772451 +0100 @@ -4,4 +4,4 @@ double ds = __builtin_nans (""); /* { dg-final { scan-assembler "\t\\.nan\tlegacy\n" } } */ -/* { dg-final { scan-assembler "\t\\.word\t2147483647\n\t\\.word\t-1\n" } } */ +/* { dg-final { scan-assembler "\t\\.word\t2147483647\n\t\\.word\t(?:-1|4294967295)\n" } } */