From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17733 invoked by alias); 7 Nov 2013 06:46:30 -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 17693 invoked by uid 48); 7 Nov 2013 06:46:26 -0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/59019] [4.9 regression] ICE in advance_target_bb, at sched-rgn.c:3561 Date: Thu, 07 Nov 2013 06:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: ice-on-valid-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: bug_status cf_reconfirmed_on cc everconfirmed 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-11/txt/msg00574.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59019 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2013-11-07 CC| |ebotcazou at gcc dot gnu.org, | |law at redhat dot com Ever confirmed|0 |1 --- Comment #1 from Jeffrey A. Law --- This is a latent bug that the path isolation code happens to expose. The fundamental problem is prior to combine we have the following RTL: (insn 25 3 6 2 (set (reg/v:SI 340 [ new_i ]) (const_int 0 [0])) j.c:225 -1 (nil)) (insn 6 25 24 2 (set (reg:BI 343) (eq:BI (reg/v:SI 340 [ new_i ]) (const_int -1 [0xffffffffffffffff]))) j.c:225 309 {*cmpsi_normal} (expr_list:REG_DEAD (reg/v:SI 340 [ new_i ]) (nil))) (insn 24 6 15 2 (trap_if (eq (reg:BI 343) (const_int 0 [0])) (const_int 0 [0])) -1 (expr_list:REG_DEAD (reg:BI 343) (nil))) (insn 15 24 16 2 (clobber (reg/i:SI 8 r8)) j.c:231 -1 (expr_list:REG_UNUSED (reg/i:SI 8 r8) (nil))) At this stage insn 24 is not considered a control flow altering insn -- it's a conditional trap. Combine does its thing and we end with: (insn 24 6 15 2 (trap_if (const_int 1 [0x1]) (const_int 0 [0])) 363 {*trap} (nil)) (insn 15 24 16 2 (clobber (reg/i:SI 8 r8)) j.c:231 -1 (expr_list:REG_UNUSED (reg/i:SI 8 r8) (nil))) Now insn 24 is an unconditional trap and is considered a control flow altering insn (see Eric's change for PR29841). Since we have a control flow altering insn in the middle of a block, we trip the checking failure. This seems like a pretty fundamental problem. I can't think of any other case where we allow optimizations to turn an insn which does not alter flow control into a flow control altering insn (obviously we allow the opposite and it's good). This means that every pass which might potentially turn a conditional trap into an unconditional trap would have to run DCE afterwards or otherwise cleanup the code after the trap to avoid this problem. Not good. Or we would have to force each optimizer which might potentially turn a conditional trap into an unconditional trap run find_many_sub_basic_blocks. Also not good. Or we could hack the ia64 port in some horrid way to avoid this problem. Even worse. I'm open to suggestions.