From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27340 invoked by alias); 28 Aug 2008 15:11:12 -0000 Received: (qmail 26219 invoked by uid 48); 28 Aug 2008 15:09:46 -0000 Date: Thu, 28 Aug 2008 15:11:00 -0000 Message-ID: <20080828150946.26218.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth at gcc dot gnu dot org" 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 X-SW-Source: 2008-08/txt/msg02246.txt.bz2 ------- Comment #7 from rguenth at gcc dot gnu dot org 2008-08-28 15:09 ------- I still think that handling NULL from evolution_part_in_loop_num is the correct thing to do. Even if you need to move this check to the analysis phase. The interesting thing is that the access function during vect_analyze_scalar_cycles_1 is {2, +, 1}_1 which is because after the vectorized part of the loop the prologue remains which has a non-constant evolution start. So with the reasoning that you analyzed the access function of the original loop properly you can probably strip the conversion that confuses you at just vect_update_ivs_after_vectorizer. (Or store the relevant information during analysis where the evolution is still simple enough) This would fix the ICE, but I wonder if it may cause wrong code because of mismatched types somehow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630