From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76975 invoked by alias); 23 Nov 2015 17:09:41 -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 76961 invoked by uid 89); 23 Nov 2015 17:09:40 -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 17:09:39 +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 AE90D251; Mon, 23 Nov 2015 17:09:38 +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 tANH9Yqj015005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Nov 2015 12:09:37 -0500 Date: Mon, 23 Nov 2015 17:11:00 -0000 From: Marek Polacek To: Richard Biener Cc: GCC Patches , Richard Sandiford Subject: Re: [PATCH] Don't ICE on symbolic ranges in VRP (PR tree-optimization/68455) Message-ID: <20151123170933.GP21807@redhat.com> References: <20151123163111.GN21807@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg02767.txt.bz2 On Mon, Nov 23, 2015 at 05:40:14PM +0100, Richard Biener wrote: > On November 23, 2015 5:31:11 PM GMT+01:00, Marek Polacek wrote: > >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? > > Hmm. I think we can do better if vr0 is symbolical - use min, max for it. > > I suppose it would be best to implement a get_integer_range () function doing that or also looking at equivalences if we are getting a symbolic range. > > Anyway, those are future enhancements that shouldn't block this patch. Is this something for this stage3? Or should I open a PR and fix it in the next stage1? > Thus OK. Thanks. Marek