------- Additional Comments From amacleod at redhat dot com 2005-08-10 15:55
-------
A quick glance shows that parse_ssa_operands() does not expect to receive a tree
that looks like:
b.c[d_5].i
get_expr_operands is called on this, and when processing COMPONENT_REF:
ref = okay_component_ref_for_subvars (expr, &offset, &size);
if (ref)
{
subvar_t svars = get_subvars_for_var (ref);
subvar_t sv;
for (sv = svars; sv; sv = sv->next)
{
bool exact;
if (overlap_subvar (offset, size, sv, &exact))
{
int subvar_flags = flags;
if (!exact)
subvar_flags &= ~opf_kill_def;
add_stmt_operand (&sv->var, s_ann, subvar_flags);
}
}
}
else
get_expr_operands (stmt, &TREE_OPERAND (expr, 0),
flags & ~opf_kill_def);
if okay_component_ref_for_subvars() is true (which it is in this case), we never
call get_expr_operands on the rest of the expression, which contains the array
ref. Therefore the operand builder never sees the use of d_5 in the expression,
and chaos breaks out as you have observed.
I dont pay much attention to the semantics of gimple, but either b.c[d_5].i is
not valid gimple, or you have to be prepared to explore the component ref deeper
in get_expr_operands. I would have expected to trip over this earlier if it was
valid, but what do I know :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23297
