From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15359 invoked by alias); 10 Oct 2013 20:47:58 -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 15317 invoked by uid 48); 10 Oct 2013 20:47:56 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/58640] [4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu Date: Thu, 10 Oct 2013 20:47: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: 4.9.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.0 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: 2013-10/txt/msg00602.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58640 --- Comment #4 from Jeffrey A. Law --- We're ending up with latches from two different loops going to the same destination due to the jump thread path passing through multiple loops. This ultimately causes the unroller to go nuts. This should be fairly easy to catch & avoid. And this brings to the forefront a question that's been slowly building in the back of my mind. Specifically, given a jump threading path, we have the ability now to lop off the tail of the path if threading all the way to the tail would ultimately force cancellation of the jump thread request. Lopping off the tail may result in better code than totally cancelling the request. This testcase is a good example. Anyway, I'll be pondering how we want to deal with that as well.