From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24961 invoked by alias); 7 Jan 2013 13:37:54 -0000 Received: (qmail 22932 invoked by uid 48); 7 Jan 2013 13:37:01 -0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/55875] [4.8 Regression] IVopts caused miscompilation Date: Mon, 07 Jan 2013 13:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00485.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55875 --- Comment #3 from Jan Hubicka 2013-01-07 13:36:58 UTC --- OK, the problem seems to be already in what simple_iv returns for SSA name 12. Here we should have -1. While analyzing the cast (gdb) p debug_gimple_stmt (at_stmt) _12 = (long unsigned int) _11; that effectively changes addition to minus, we get to CASE_CONVERT: /* In case we have a truncation of a widened operation that in the truncated type has undefined overflow behavior analyze the operation done in an unsigned type of the same precision as the final truncation. We cannot derive a scalar evolution for the widened operation but for the truncated result. */ if (TREE_CODE (type) == INTEGER_TYPE && TREE_CODE (TREE_TYPE (rhs1)) == INTEGER_TYPE && TYPE_PRECISION (type) < TYPE_PRECISION (TREE_TYPE (rhs1)) && TYPE_OVERFLOW_UNDEFINED (type) && TREE_CODE (rhs1) == SSA_NAME && (def = SSA_NAME_DEF_STMT (rhs1)) && is_gimple_assign (def) && TREE_CODE_CLASS (gimple_assign_rhs_code (def)) == tcc_binary && TREE_CODE (gimple_assign_rhs2 (def)) == INTEGER_CST) { tree utype = unsigned_type_for (type); chrec1 = interpret_rhs_expr (loop, at_stmt, utype, gimple_assign_rhs1 (def), gimple_assign_rhs_code (def), gimple_assign_rhs2 (def)); } else chrec1 = analyze_scalar_evolution (loop, rhs1); Here for widening conversions we do nothing. So we get unit size align 32 symtab 0 alias set -1 canonical type 0x7ffff6ee8690 precision 32 min max pointer_to_this > arg 0 constant 1> arg 1 constant 4294967295> arg 2 constant 1>> this is correct, since it is done in unsigned int. Next we do: res = chrec_convert (type, chrec1, at_stmt); Eventually we go to convert_affine_scev and we set enforce_overflow_semantics enforce_overflow_semantics = (use_overflow_semantics && nowrap_type_p (type)); This test looks backwards to me. If the type is nowrap, we do not need to enforce anything about overflows, when it is wrap, then we have to. Flipping it however do not change fix the testcase. Anyway, the result of convert_affince_scev makes us to produce unit size align 64 symtab 0 alias set -1 canonical type 0x7ffff6ee87e0 precision 64 min max > arg 0 constant 1> arg 1 constant 4294967295> arg 2 constant 1>> that seems already wrong. So the bug seems to be that convert_affince_scev is not doing the right thing here? But what the right thing is? Conversion to -1 or giving up?