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?
--
Summary: ICE in loop_depth_of_name
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27056
