Hi Steve,
On Fri, 15 Apr 2011, Steve Ellcey wrote:
> I was curious if anyone was still looking at this problem?
I didn't because it occurred only on an experimental port.
> I see this on IA64 HP-UX in 32 bit mode
Which means it also occurs with something else now (well, ia64 hp-ux, but
at least something :) )
> to do. The tree (treeop0) that op0 is generated from is below and when
> we call expr_expr the modifier is EXPAND_INITIALIZER. Should
> expand_expr return an SImode expression for this tree (ptr_mode) or a
> DImode expression (Pmode) in this case?
Callers of expand_expr are expected to deal with the situation that the
returned object doesn't have the desired mode, hence I think it's okay for
expand_expr to return a DImode code_label rtx. Meaning we have to deal
with it. The patch of HJ is a first step but doesn't cater for op0 being
a CONST_INT, which doesn't have a mode, hence at the very least the code
should look like:
enum machine_mode inner_mode = GET_MODE (op0);
if (inner_mode == VOIDmode)
inner_mode = TYPE_MODE (inner_type);
I do wonder what other places in expand really would need something
similar. Right now nothing else ICEs but perhaps silently generates code
that only works by accident. Well, I guess we'll see.
Ciao,
Michael.
