From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16868 invoked by alias); 13 Aug 2013 17:25:44 -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 16854 invoked by uid 89); 13 Aug 2013 17:25:44 -0000 X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS autolearn=ham version=3.3.2 Received: from mail-ea0-f180.google.com (HELO mail-ea0-f180.google.com) (209.85.215.180) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 13 Aug 2013 17:25:44 +0000 Received: by mail-ea0-f180.google.com with SMTP id h10so4284659eaj.25 for ; Tue, 13 Aug 2013 10:25:41 -0700 (PDT) X-Received: by 10.15.41.77 with SMTP id r53mr4403524eev.64.1376414741756; Tue, 13 Aug 2013 10:25:41 -0700 (PDT) Received: from localhost ([2.26.203.233]) by mx.google.com with ESMTPSA id bn13sm67871590eeb.11.2013.08.13.10.25.40 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 13 Aug 2013 10:25:41 -0700 (PDT) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,Steve Ellcey , , rdsandiford@googlemail.com Cc: Steve Ellcey , Subject: Re: MIPS tests (nan-legacy.c and nans-legacy.c) failing References: <9f69a43f-c31f-4c49-aaa0-b022fd602f52@BAMAIL02.ba.imgtec.org> <87fvul5k37.fsf@talisman.default> Date: Tue, 13 Aug 2013 17:25:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Tue, 13 Aug 2013 14:28:34 +0100") Message-ID: <87ioz9iju3.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-08/txt/msg00748.txt.bz2 "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/ > * gcc.target/mips/nan-legacy.c: Accept 4294967295 as an > alternative to -1. > * gcc.target/mips/nans-legacy.c: Likewise. OK, thanks. Richard