From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27247 invoked by alias); 2 Apr 2013 11:19:42 -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 27201 invoked by uid 48); 2 Apr 2013 11:19:35 -0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/56778] [4.9 Regression] ICE on several benchmarks after r196775. Date: Tue, 02 Apr 2013 11:19: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: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.9.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 X-SW-Source: 2013-04/txt/msg00104.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56778 --- Comment #2 from Richard Biener 2013-04-02 11:19:35 UTC --- The issue is that gimple_seq_add_seq updates stmts added. But we update SSA form _before_ adding the sequence into the IL stream: /* End loop-exit-fixes after versioning. */ update_ssa (TODO_update_ssa); if (cond_expr_stmt_list) { cond_exp_gsi = gsi_last_bb (condition_bb); gsi_insert_seq_before (&cond_exp_gsi, cond_expr_stmt_list, GSI_SAME_STMT); } gimplify.c has a function that does gimple_seq_add_seq_without_update. There are two ways to fix this, one is to insert the sequence before updating SSA form, another is to consistently use gimple_seq_add_seq_without_update. Or to make gimple_seq_add_seq not update stmts (sequences are inserted later anyway, which can do the update). Not sure why it would make sense at all to update stmt operands for sth not in the IL ... Well. I'm going for the first. Which doesn't fix it because we create an alias-check for a load of a load appearantly where the latter is not loop invariant. I presume this is GATHER support, and eventually the DDR mangling in data-ref analysis I removed did avoid this to happen.