Does zero_extend (const_int) *ever* have a valid meaning

[Richard Earnshaw <rearnsha at arm dot com>]

I'm trying to track down a failure in the testsuite for arm-elf 
(specifically gcc.c-torture/execute/961213-1.c) which ICEs in cse when 
compiled with

	-O3 -fomit-frame-pointer -funroll-loops

The problem is the following pair of insns:

(insn 153 152 157 0 (nil) (set (reg/v:DI 67)
        (const_int 0 [0x0])) -1 (nil)
    (expr_list:REG_EQUAL (const_int 0 [0x0])
        (nil)))

(insn 157 153 158 0 0x4001c3f4 (set (reg:DI 69)
        (mult:DI (zero_extend:DI (subreg:SI (reg/v:DI 67) 0))
            (zero_extend:DI (subreg:SI (reg:DI 48) 0)))) -1 (nil)
    (expr_list:REG_EQUAL (ashift:DI (zero_extend:DI (subreg:SI (reg/v:DI 
67) 0))
            (const_int 4 [0x4]))
        (nil)))

The problem occurs when cse tries to operate on the REG_EQUAL note.  In 
that case it reaches the point where it tries to simplify the SUBREG and 
discovers that the value is (const_int 0).

It replaces the (subreg:SI (reg/v:DI 67) 0) with (const_int 0) using 
validate_change, giving

(insn 157 153 158 0 0x4001c3f4 (set (reg:DI 69)
        (mult:DI (zero_extend:DI (subreg:SI (reg/v:DI 67) 0))
            (zero_extend:DI (subreg:SI (reg:DI 48) 0)))) -1 (nil)
    (expr_list:REG_EQUAL (ashift:DI (zero_extend:DI (const_int 0 [0x0]))
            (const_int 4 [0x4]))
        (nil)))

which of course validates successfully because the change is in the note 
not the pattern of the insn.

However, it then tries to take the cost of this expression and 
arm_rtx_cost is aborting because zero_extend (const_int) is not supposed 
to be legal (VOIDmode has no size, so we don't know which bit to start 
extending from -- hence we don't know how much the operation will cost).

So, is cse correct in trying to make this substitution?  If so, is 
arm_rtx_costs incorrect to try and fault this case.  And if so, what does 
zero_extend(const_int) really mean?

R.