From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 102528 invoked by alias); 27 Apr 2015 09:15:00 -0000 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 Received: (qmail 102468 invoked by uid 48); 27 Apr 2015 09:14:56 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/65875] [5/6 Regression] ICE: Segmentation fault Date: Mon, 27 Apr 2015 09:15: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-Version: 5.1.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.2 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-04/txt/msg02248.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65875 --- Comment #4 from Richard Biener --- (In reply to Jakub Jelinek from comment #3) > Created attachment 35395 [details] > gcc5-pr65875.patch > > Untested fix. IMHO vrp_visit_phi_node was missing the vr_result VR_VARING > handling if the value range turned into varying only during > update_value_range, and also update_value_range wasn't telling the caller if > it changed it into varying late. > > That said, the testcase has conditionally undefined variable, and checking > whether all the VRP decisions (first and second pass) are sane, would be > nice, Richard, could you please have a look? > E.g. I find it strange that h has VR [0, LONG_MAX] before VRP2, when it > really has just values 0 or 1, so should be ideally [0, 1]. Or that i has > value range [1, LONG_MAX] - it is conditionally undefined (that is ignored), > and conditionally negation of an int variable (only if that int variable is > negative). The negated int variable is [1, +INF(OVF)] because INT_MIN might > overflow, perhaps if we really need to preserve the OVF flag, we have to use > [1, +INF(OVF)] again rather than just [1, 0x7fffffff] :(. For h we get into the loop PHI handling code which drops to INF-1 if it iterates "too much". The rest probably ripples down from that. I can't see where that [1, 0x7ffffff] issue happens.