From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11125 invoked by alias); 13 Aug 2013 21:53:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11115 invoked by uid 89); 13 Aug 2013 21:53:09 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.2 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 13 Aug 2013 21:53:08 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1V9MWY-0006OG-Ol from Maciej_Rozycki@mentor.com ; Tue, 13 Aug 2013 14:53:06 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Aug 2013 14:53:06 -0700 Received: from [172.30.64.154] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Tue, 13 Aug 2013 22:53:05 +0100 Date: Tue, 13 Aug 2013 21:53:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford CC: Steve Ellcey , Subject: Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing In-Reply-To: <87ioz9iju3.fsf@talisman.default> Message-ID: References: <9f69a43f-c31f-4c49-aaa0-b022fd602f52@BAMAIL02.ba.imgtec.org> <87fvul5k37.fsf@talisman.default> <87ioz9iju3.fsf@talisman.default> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-08/txt/msg00763.txt.bz2 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