From owner-freebsd-bugs@FreeBSD.ORG Tue Feb 1 19:10:10 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B2BA1065673 for ; Tue, 1 Feb 2011 19:10:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 760F08FC1F for ; Tue, 1 Feb 2011 19:10:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p11JA67i086606 for ; Tue, 1 Feb 2011 19:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p11JA6bb086605; Tue, 1 Feb 2011 19:10:06 GMT (envelope-from gnats) Resent-Date: Tue, 1 Feb 2011 19:10:06 GMT Resent-Message-Id: <201102011910.p11JA6bb086605@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Pedro Giffuni Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCD75106566C for ; Tue, 1 Feb 2011 19:07:57 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id AF9A58FC13 for ; Tue, 1 Feb 2011 19:07:57 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id p11J7vlT036890 for ; Tue, 1 Feb 2011 19:07:57 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id p11J7v2i036889; Tue, 1 Feb 2011 19:07:57 GMT (envelope-from nobody) Message-Id: <201102011907.p11J7v2i036889@red.freebsd.org> Date: Tue, 1 Feb 2011 19:07:57 GMT From: Pedro Giffuni To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: gnu/154445: Attempt to "fix" gcc -ftree-vrp X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:10:10 -0000 >Number: 154445 >Category: gnu >Synopsis: Attempt to "fix" gcc -ftree-vrp >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Feb 01 19:10:06 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Pedro Giffuni >Release: 8.1-Release >Organization: >Environment: FreeBSD mogwai.giffuni.net 8.1-RELEASE FreeBSD 8.1-RELEASE #1: Sat Jul 17 14:19:59 PDT 2010 root@build8x64.pcbsd.org:/usr/obj/usr/pcbsd-build81/fbsd-source/8.1/sys/PCBSD amd64 >Description: gcc's tree-vrp optimization was turned of by default on FreeBSD (svn 172419) because it's known to generate bad code, specially on java ports, Looking at the gcc 4.2 branch logs I found the following change that appears to fix it. 2007-10-10 Richard Guenther PR tree-optimization/33099 PR tree-optimization/33381 * tree-vrp.c (adjust_range_with_scev): Do not adjust ranges from pointer typed chrecs. Unfortunately this change is GPL3 and the owner will not reconsider changing the license. A workaround that seems to work in my system is undoing the last patch in that file/function. This is not the ideal fix but since the code is disabled by default anyways it works well enough. >How-To-Repeat: Check gcc PR 330099 and build the testcase with -ftree-vrp >Fix: REVERSE (patch -R) the attached patch in /usr/src/contrib: 2007-06-04 Ian Lance Taylor * tree-vrp.c (adjust_range_with_scev): When loop is not expected to overflow, reduce overflow infinity to regular infinity. Patch attached with submission follows: --- gcc/tree-vrp.c 2007/05/30 22:52:02 125204 +++ gcc/tree-vrp.c 2007/06/04 21:58:42 125320 @@ -2558,6 +2558,13 @@ if (compare_values (min, max) == 1) return; } + + /* According to the loop information, the variable does not + overflow. If we think it does, probably because of an + overflow due to arithmetic on a different INF value, + reset now. */ + if (is_negative_overflow_infinity (min)) + min = tmin; } else { @@ -2570,12 +2577,61 @@ if (compare_values (min, max) == 1) return; } + + if (is_positive_overflow_infinity (max)) + max = tmax; } set_value_range (vr, VR_RANGE, min, max, vr->equiv); } } +/* Return true if VAR may overflow at STMT. This checks any available + loop information to see if we can determine that VAR does not + overflow. */ + +static bool +vrp_var_may_overflow (tree var, tree stmt) +{ + struct loop *l; + tree chrec, init, step; + + if (current_loops == NULL) + return true; + + l = loop_containing_stmt (stmt); + if (l == NULL) + return true; + + chrec = instantiate_parameters (l, analyze_scalar_evolution (l, var)); + if (TREE_CODE (chrec) != POLYNOMIAL_CHREC) + return true; + + init = initial_condition_in_loop_num (chrec, l->num); + step = evolution_part_in_loop_num (chrec, l->num); + + if (step == NULL_TREE + || !is_gimple_min_invariant (step) + || !valid_value_p (init)) + return true; + + /* If we get here, we know something useful about VAR based on the + loop information. If it wraps, it may overflow. */ + + if (scev_probably_wraps_p (init, step, stmt, + current_loops->parray[CHREC_VARIABLE (chrec)], + true)) + return true; + + if (dump_file && (dump_flags & TDF_DETAILS) != 0) + { + print_generic_expr (dump_file, var, 0); + fprintf (dump_file, ": loop information indicates does not overflow\n"); + } + + return false; +} + /* Given two numeric value ranges VR0, VR1 and a comparison code COMP: @@ -4786,7 +4842,8 @@ if (vrp_val_is_max (vr_result.max)) goto varying; - if (!needs_overflow_infinity (TREE_TYPE (vr_result.min))) + if (!needs_overflow_infinity (TREE_TYPE (vr_result.min)) + || !vrp_var_may_overflow (lhs, phi)) vr_result.min = TYPE_MIN_VALUE (TREE_TYPE (vr_result.min)); else if (supports_overflow_infinity (TREE_TYPE (vr_result.min))) vr_result.min = @@ -4804,7 +4861,8 @@ if (vrp_val_is_min (vr_result.min)) goto varying; - if (!needs_overflow_infinity (TREE_TYPE (vr_result.max))) + if (!needs_overflow_infinity (TREE_TYPE (vr_result.max)) + || !vrp_var_may_overflow (lhs, phi)) vr_result.max = TYPE_MAX_VALUE (TREE_TYPE (vr_result.max)); else if (supports_overflow_infinity (TREE_TYPE (vr_result.max))) vr_result.max = >Release-Note: >Audit-Trail: >Unformatted: