From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27500 invoked by alias); 28 Apr 2005 19:34:14 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 27282 invoked by uid 48); 28 Apr 2005 19:33:33 -0000 Date: Thu, 28 Apr 2005 19:34:00 -0000 Message-ID: <20050428193333.27281.qmail@sourceware.org> From: "kazu at cs dot umass dot edu" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050414204122.21030.janis@gcc.gnu.org> References: <20050414204122.21030.janis@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug tree-optimization/21030] [4.1 Regression] ICE in set_value_range building 176.gcc with -O2 X-Bugzilla-Reason: CC X-SW-Source: 2005-04/txt/msg03999.txt.bz2 List-Id: ------- Additional Comments From kazu at cs dot umass dot edu 2005-04-28 19:33 ------- Diego, I think it's OK to have contradictory information from an ASSERT_EXPR and SCEV. Let's say we have a loop counting from i = 0 upward. It's possible that we "if (i < 0)" in the loop and see something like i_10 = ASSERT_EXPR ; on the "then" arm of the conditional. In this case, we know we are counting upward, so SCEV tells us that the minimum value of i_10 should be 0, but the ASSERT_EXPR tells us that the range should be [-INF, -1]. They are completely disjoint! This weird situation comes from the fact that the "then" branch of the conditional is dead. In this case, probably the safest and simplest thing to do is to ignoring what SCEV says. Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21030