From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27341 invoked by alias); 23 Nov 2015 16:31:21 -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 27332 invoked by uid 89); 23 Nov 2015 16:31:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 23 Nov 2015 16:31:19 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 53553C0A1467; Mon, 23 Nov 2015 16:31:17 +0000 (UTC) Received: from redhat.com (ovpn-204-24.brq.redhat.com [10.40.204.24]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tANGVC0L018600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Nov 2015 11:31:15 -0500 Date: Mon, 23 Nov 2015 16:36:00 -0000 From: Marek Polacek To: GCC Patches Cc: Richard Biener , Richard Sandiford Subject: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455) Message-ID: <20151123163111.GN21807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg02756.txt.bz2 We blow up on the following testcase because we find ourselves passing [_13 + 1, INT_MAX] as a vr1 to extract_range_from_multiplicative_op_1; that's bad because this function immediately calls vrp_int_const_binop which just doesn't work for symbolic ranges, it only wants int_csts. This started with Richards S.'s changes in r228614 -- we're now since able to recurse into SSA names, thus get better info about ranges. That means that range_includes_zero_p in extract_range_from_binary_expr_1 for the *_DIV_EXPR cases was able to determine that the range doesn't include zero, so we went through a different code path and ended up calling extract_range_from_multiplicative_op_1 even with symbolic ranges. I couldn't come up with anything better than checking that we're dealing with nonsymbolic ranges for such a case. Bootstrapped/regtested on x86_64-linux, ok for trunk? 2015-11-23 Marek Polacek PR tree-optimization/68455 * tree-vrp.c (extract_range_from_binary_expr_1): Don't call extract_range_from_multiplicative_op_1 on symbolic ranges. * gcc.dg/tree-ssa/pr68455.c: New test. diff --git gcc/testsuite/gcc.dg/tree-ssa/pr68455.c gcc/testsuite/gcc.dg/tree-ssa/pr68455.c index e69de29..6b46b30 100644 --- gcc/testsuite/gcc.dg/tree-ssa/pr68455.c +++ gcc/testsuite/gcc.dg/tree-ssa/pr68455.c @@ -0,0 +1,19 @@ +/* PR tree-optimization/68455 */ +/* { dg-do compile } */ +/* { dg-options "-O2" } */ + +int r; +int n; + +void +fn1 (void) +{ + int i; + + for (i = 0; i < 1; ++i) + { + unsigned short int u; + if (u < n) + r = 1 / n; + } +} diff --git gcc/tree-vrp.c gcc/tree-vrp.c index 7001190..acbb70b 100644 --- gcc/tree-vrp.c +++ gcc/tree-vrp.c @@ -3015,7 +3015,7 @@ extract_range_from_binary_expr_1 (value_range *vr, return; } } - else + else if (!symbolic_range_p (&vr0) && !symbolic_range_p (&vr1)) { extract_range_from_multiplicative_op_1 (vr, code, &vr0, &vr1); return; Marek