More problems with Oct 28 bulk merge

[Jeffrey A Law <law at cygnus dot com>]

Sigh, yet another bug in your bulk merge.  Something in those combine changes 
is mucking up the m68k port.

Given a sequence of instructions like this:

(insn 736 790 738 (set (cc0)
        (reg/v:SI 30)) 5 {tstsi+1} (nil)
    (nil))

(insn 738 736 739 (set (reg:QI 129)
        (eq:QI (cc0)
            (const_int 0 [0x0]))) 361 {seq+1} (nil)
    (nil))

(insn 739 738 740 (set (reg:SI 128)
        (sign_extend:SI (reg:QI 129))) 89 {extendqisi2} (insn_list 738 (nil))
    (expr_list:REG_DEAD (reg:QI 129)
        (nil)))

(insn 740 739 159 (set (reg:SI 130)
        (and:SI (reg:SI 128)
            (const_int 4 [0x4]))) 219 {andsi3_internal} (insn_list 739 (nil))
    (expr_list:REG_DEAD (reg:SI 128)
        (nil)))

Combine is incorrectly determining that reg130 should have the value zero,
when it could have either the value zero or the value 4.

Remember, STORE_FLAG_VALUE on the m68k is -1.

So reg129 will have the value 0 or 0xff

So reg 128 will have the value 0 or 0xffffffff

So reg 130 will have the value 0 or 4

The most likely culprit to me would be the change to if_then_else_cond:

        * combine.c (simplify_comparison): When making comparison in wider
        mode, check for having commuted an AND and a SUBREG.
        (contains_muldiv): New function.
        (try_combine): Call it when dividing a PARALLEL.
        (simplify_rtx, case TRUNCATE): Don't remove for umulsi3_highpart.
        (simplify_comparison, case ASHIFTRT): Recognize sign-extension of
        a PLUS.
        (record_value_for_reg): If TEM is a binary operation with two CLOBBERs,
        use one of the CLOBBERs instead.
        (if_then_else_cond): If comparing against zero, just return thing
        being compared.

Compile the attached testcase with -O2 using an m68k cross compiler.