From patchwork Mon Jan 7 21:02:23 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 210238 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]) by ozlabs.org (Postfix) with SMTP id 17B9F2C0095 for ; Tue, 8 Jan 2013 08:02:37 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1358197358; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To: MIME-Version:Content-Type:Content-Disposition:User-Agent: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=uIFReMf9KrSJBZEVFaPF Ij86ULE=; b=XVX6XOE2us9okbLeyDUix9k7fwE1AEojWawf3K5P6W5lxuwU2dHW fBKwn8+pEviAzdX/5q6l1pUqYrRy3xBJwqDcvyMeoMUY49GyOxkXlwN3fISZQELn 0MCawFBmDFhiaYMn9fQxSRu/U8jNjfubhKs2yUKbSzwhezG6DJeSM4k= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:MIME-Version:Content-Type:Content-Disposition:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=K0N+Ttbk/EDD1LQmq78Q598qKYoXh21/nFM6ii2fs/62DYse8hG+m1ey2DcDDS q9MJwuENpcFSI/mdq6BMPAVDdZjvef/cfJ0/M2qldirKUgzE+WxDeqgs1MazKprG LyYgdgMa3m5bIgjws1IGc2PZy3s4ZqtUSl1Lo4GRMh+Fk=; Received: (qmail 4837 invoked by alias); 7 Jan 2013 21:02:34 -0000 Received: (qmail 4826 invoked by uid 22791); 7 Jan 2013 21:02:33 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Jan 2013 21:02:27 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r07L2R7x014029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jan 2013 16:02:27 -0500 Received: from zalov.redhat.com (vpn1-4-27.ams2.redhat.com [10.36.4.27]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r07L2OSx001760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Jan 2013 16:02:26 -0500 Received: from zalov.cz (localhost [127.0.0.1]) by zalov.redhat.com (8.14.5/8.14.5) with ESMTP id r07L2OnF023737; Mon, 7 Jan 2013 22:02:24 +0100 Received: (from jakub@localhost) by zalov.cz (8.14.5/8.14.5/Submit) id r07L2N7t023736; Mon, 7 Jan 2013 22:02:23 +0100 Date: Mon, 7 Jan 2013 22:02:23 +0100 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Minor VRP simplify_float_conversion_using_ranges tweaks (PR tree-optimization/54120) Message-ID: <20130107210223.GG7269@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes 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 Hi! As mentioned in the PR, the actual important bug has been fixed in range_fits_type_p by Richard Sandiford recently, so here are just two minor nits. An extension of a signed src_type to unsigned wider type is fine only if the vr doesn't have negative min or max, so always assuming we can extend is wrong (but not a very big deal, as we always pass unsigned_p = false when calling the function right now). The other change mattered in 4.7 where CODE_FOR_nothing is a big number, in 4.8 it is just a consistency issue when all the other can_float_p calls are compared with CODE_FOR_nothing (== 0). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? What about 4.7 (together with backport of Richard's http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194800 fix) after a while? 2013-01-07 Jakub Jelinek PR tree-optimization/54120 * tree-vrp.c (range_fits_type_p): Don't allow src_precision < precision from signed vr to unsigned_p if vr->min or vr->max is negative. (simplify_float_conversion_using_ranges): Test can_float_p against CODE_FOR_nothing. Jakub --- gcc/tree-vrp.c.jj 2013-01-02 21:05:34.137069022 +0100 +++ gcc/tree-vrp.c 2013-01-07 18:15:32.088880351 +0100 @@ -8753,9 +8753,11 @@ range_fits_type_p (value_range_t *vr, un && !POINTER_TYPE_P (src_type)) return false; - /* An extension is always fine, so is an identity transform. */ + /* An extension is fine unless VR is signed and unsigned_p, + and so is an identity transform. */ src_precision = TYPE_PRECISION (TREE_TYPE (vr->min)); - if (src_precision < precision + if ((src_precision < precision + && !(unsigned_p && !TYPE_UNSIGNED (src_type))) || (src_precision == precision && TYPE_UNSIGNED (src_type) == unsigned_p)) return true; @@ -8813,7 +8815,7 @@ simplify_float_conversion_using_ranges ( mode = TYPE_MODE (TREE_TYPE (rhs1)); /* If we can do the conversion in the current input mode do nothing. */ else if (can_float_p (fltmode, TYPE_MODE (TREE_TYPE (rhs1)), - TYPE_UNSIGNED (TREE_TYPE (rhs1)))) + TYPE_UNSIGNED (TREE_TYPE (rhs1))) != CODE_FOR_nothing) return false; /* Otherwise search for a mode we can use, starting from the narrowest integer mode available. */