From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113476 invoked by alias); 24 Apr 2015 19:23:05 -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 113411 invoked by uid 89); 24 Apr 2015 19:23:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 24 Apr 2015 19:23:03 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3OJN2fK019618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 24 Apr 2015 15:23:02 -0400 Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3OJN08e032481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 24 Apr 2015 15:23:01 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t3OJMwr7002677; Fri, 24 Apr 2015 21:22:58 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t3OJMuUi002676; Fri, 24 Apr 2015 21:22:56 +0200 Date: Fri, 24 Apr 2015 19:23:00 -0000 From: Jakub Jelinek To: Richard Biener Cc: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix VRP update_value_range and caller (PR tree-optimization/65875) Message-ID: <20150424192256.GO1751@tucnak.redhat.com> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg01525.txt.bz2 Hi! In vrp_visit_assignment_or_call we try to return SSA_PROP_VARYING if update_value_range returned true and the new range is VR_VARYING, but vrp_visit_phi_node fails to do that. Another thing is that if update_value_range decides to set_value_range_to_varying (old_vr); it doesn't update new_vr, so the caller doesn't know the new vr is varying (and calling get_value_range again sounds unnecessary). The following patch fixes it, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk and 5.2? 2015-04-24 Jakub Jelinek PR tree-optimization/65875 * tree-vrp.c (update_value_range): If in is_new case setting old_vr to VR_VARYING, also set new_vr to it. (vrp_visit_phi_node): Return SSA_PROP_VARYING instead of SSA_PROP_INTERESTING if update_value_range returned true, but new range is VR_VARYING. * gcc.c-torture/compile/pr65875.c: New test. --- gcc/tree-vrp.c.jj 2015-04-20 14:35:39.000000000 +0200 +++ gcc/tree-vrp.c 2015-04-24 18:10:41.321367440 +0200 @@ -892,7 +892,12 @@ update_value_range (const_tree var, valu UNDEFINED or from VARYING. */ if (new_vr->type == VR_UNDEFINED || old_vr->type == VR_VARYING) - set_value_range_to_varying (old_vr); + { + BITMAP_FREE (new_vr->equiv); + set_value_range_to_varying (old_vr); + set_value_range_to_varying (new_vr); + return true; + } else set_value_range (old_vr, new_vr->type, new_vr->min, new_vr->max, new_vr->equiv); @@ -8941,6 +8946,9 @@ update_range: fprintf (dump_file, "\n"); } + if (vr_result.type == VR_VARYING) + return SSA_PROP_VARYING; + return SSA_PROP_INTERESTING; } --- gcc/testsuite/gcc.c-torture/compile/pr65875.c.jj 2015-04-24 18:20:47.650595581 +0200 +++ gcc/testsuite/gcc.c-torture/compile/pr65875.c 2015-04-24 18:20:30.000000000 +0200 @@ -0,0 +1,24 @@ +/* PR tree-optimization/65875 */ + +int a, b, c, d, e, f, g; + +void +foo (void) +{ + long h = 0, i; + if (g < 0) + i = -g; + for (; b;) + for (; c;) + if (e) + h = 1; + for (; f;) + if (a) + break; + if (h > i) + while (h > i) + { + d = 0; + h--; + } +} Jakub