On the attached testcase with today's gcc-4_1-branch -m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing minor changes in different routines makes the problem go away. What I see in the dumps is: 1) at *t26.ssa, in draw_digit, there are two SSA_NAMEs with version 2: ... D.52296_2 = dD.52286_1 * 2; # VUSE <digit_texture_coordsD.52285_3>; x1D.52291_4 = digit_texture_coordsD.52285[D.52296_2]; D.52296_5 = dD.52286_1 * 2; D.52297_6 = D.52296_5 + 1; # VUSE <digit_texture_coordsD.52285_3>; y1D.52292_7 = digit_texture_coordsD.52285[D.52297_6]; x2D.52293_8 = x1D.52291_4 + 2.5e-1; y2D.52294_9 = y1D.52292_7 + 2.5e-1; # VUSE <cfgD.24335_2>; ... 2) when DCE is run, it first sees cfgD.24335_2 and sets bit 2 in processed bitmap in mark_operand_necessary, later on thus removes the D.52296_2 = dD.52286_1 * 2; statement as dead, eventhough it is not dead, yet keeps the other 2 uses of D.52296_2 around 3) in copyprop, we look at D.52296_2 which is on the free list in the mean time and crash because it's SSA_NAME_DEF_STMT is NULL in bb_for_stmt called from loop_depth_of_name. Is already 1) a bug? BTW, in *t26.ssa I see cfgD.24335_2 being used in 2 different functions, load_background_image and draw_digit, in both cases only in VUSE<>. Maybe some tree sharing issue?
Created attachment 11216 [details] 188125.ii.bz2
The ICE was probably exposed by my changes for PR26830, but if I understand right it was causing a wrong code before that?
I get the same ICE also with gcc version 4.1.0 20060304 (Red Hat 4.1.0-3) which is much older than your PR26830 fix. So those 2 seem to be unrelated.
*** This bug has been marked as a duplicate of 26757 ***
Subject: Re: New: ICE in loop_depth_of_name On Thu, 2006-04-06 at 11:49 +0000, jakub at gcc dot gnu dot org wrote: > On the attached testcase with today's gcc-4_1-branch > -m32 -g -O2 I get ICE during copy propagation. Unfortunately, even doing minor > changes in different routines makes the problem go away. > What I see in the dumps is: > 1) at *t26.ssa, in draw_digit, there are two SSA_NAMEs with version 2: This is already wrong :)