From patchwork Mon Dec 30 15:24:48 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 305785 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id EFAFD2C00E4 for ; Tue, 31 Dec 2013 02:27:59 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type; q=dns; s= default; b=akZbskYsCnxt5IG8VzAFOeXYZiW1s97o8LJjUcXcRVmJs+Kq80eHl b9kR94BEwGDThj5ew05IP/ZPCErRH9srNrGAtv3ZcDemt0g1EF1dWA8tTtL5fVIm y6h2sReSmXKHnaNdvOTtgYUriL+WCH8B9XdbXBE5fKbsxR+nzHNIug= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type; s= default; bh=7H1SuvQC4y70dPtEpojNr+3RnJU=; b=JiYul2oGHl8Gh67LyTbo OMTDE/p006uzzDXL2u14zOarUUISknwO9J4bwjaLi2s0EEyICvJpDRpi7ayDBzR5 n6CkulSIvevNqiUizko1OwXZfKOhKdmJH5S68gUnIBHYfhwe2JFoTZOwe7mseB8B 7VSzRv/6nc7wH/a5Xl58AWc= Received: (qmail 30069 invoked by alias); 30 Dec 2013 15:27:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 30058 invoked by uid 89); 30 Dec 2013 15:27:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 30 Dec 2013 15:27:50 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBUFRm4q031026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Dec 2013 10:27:49 -0500 Received: from Cadeux.redhat.com (vpn1-4-205.ams2.redhat.com [10.36.4.205]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBUFRjVd023284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 30 Dec 2013 10:27:47 -0500 From: Nick Clifton To: gcc-patches@gcc.gnu.org Subject: RFA: Use precision in get_mode_bounds() Date: Mon, 30 Dec 2013 15:24:48 +0000 Message-ID: <87zjni745b.fsf@redhat.com> MIME-Version: 1.0 X-IsSubscribed: yes Hi Guys, I have tracked down a bug reported against the MSP430 (PR target/59613) which turns out to be a generic problem. The function get_mode_bounds() in stor-layout.c computes the minimum and maximum values for a given mode, but it uses the bitsize of the mode not the precision. This is incorrect if the two values are different, (which can happen when the target is using partial integer modes), since values outside of the precision cannot be stored in the mode, no matter how many bits the mode uses. The result, for the MSP430 in LARGE mode, is that calling get_mode_bounds() on PSImode returns a maximum value of -1 instead of 1^20. Note - what happens is that get_mode_bounds computes the maximum as (1 << 31) - 1 and then calls gen_int_mode to create an RTX for this value. But gen_int_mode calls trunc_int_for_mode which uses GET_MODE_PRECISION to determine the sign bits and these bits overwrite some of the zero bits in (1 << 31) - 1 changing it into -1. The result of this behaviour is the bug that I was tracking down. simplify_const_relational_operation() was erroneously discarding a comparison of a pointer against zero, because get_mode_bounds told it that the pointer could only have values between 0 and -1... The proposed patch is simple - use the mode's precision and not its bitsize to compute the bounds. This seems like an obvious fix, but I am not familiar with all of the uses of get_mode_bounds() so maybe there is a situation where using the bitsize is correct. There were no regressions and several fixed test cases with the msp430-elf toolchain that I was using, and no regressions with an i686-pc-linux-gnu toolchain. OK to apply ? Cheers Nick PS. Just found out that the same patch was created by Peter Bigot for a different PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 gcc/ChangeLog 2013-12-30 Nick Clifton PR target/59631 * stor-layout.c (get_mode_bounds): Use GET_MODE_PRECISION instead of GET_MODE_BITSIZE. Index: stor-layout.c =================================================================== --- stor-layout.c (revision 206241) +++ stor-layout.c (working copy) @@ -2816,7 +2816,8 @@ enum machine_mode target_mode, rtx *mmin, rtx *mmax) { - unsigned size = GET_MODE_BITSIZE (mode); + /* PR 59613: Use the precision of the mode, not its bitsize. */ + unsigned size = GET_MODE_PRECISION (mode); unsigned HOST_WIDE_INT min_val, max_val; gcc_assert (size <= HOST_BITS_PER_WIDE_INT);