ICEs in validate_replace_src

["Zack Weinberg" <zackw at stanford dot edu>]

validate_replace_src aborts if GET_CODE (PATTERN (insn)) != SET.  It
should probably be using single_set, but that is irrelevant to the
bootstrap failures, because it's being called on a genuine double set,
at least on i386:

(insn/i 100 99 101 (parallel[ 
            (set (reg:SI 80)
                (udiv:SI (reg:SI 79)
                    (reg/v:SI 62)))
            (set (reg:SI 81)
                (umod:SI (reg:SI 79)
                    (reg/v:SI 62)))
            (clobber (reg:CC 17 flags))
        ] ) 192 {udivmodsi4} (nil)
    (nil))

Global constant propagation wants to replace (reg/v:SI 62) with
(const_int 0) - yeah, that seems odd to me too.

I am inclined to suspect this patch:

Fri Feb 16 12:41:30 2001  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>

	* gcse.c (hash_scan_set): If cprop, see if REG_EQUAL or REG_EQUIV.
	Don't CSE a nop.
	(hash_scan_insn): Clean up calls to hash_scan_set.
	(compute_kill_rd): REGNO now unsigned.
	(try_replace_reg): Rework to use simplify_replace_rtx.
	(cprop_jump, cprop_cc0_jump): Likewise.
	(cprop_insn): Call find_reg_equal_equiv_note.
	Reflect changes to cprop_jump and cprop_cc0_jump.

Before the change, try_replace_reg would still have called 
validate_replace_src on this insn, so the bug is in some other part of
the patch.  Here's a backtrace.

#0  fancy_abort (file=0x83ac360 "/work/src/vanilla.gcc/gcc/recog.c", line=754, 
    function=0x83ac4a0 "validate_replace_src")
    at /work/src/vanilla.gcc/gcc/diagnostic.c:1762
#1  0x82889f7 in validate_replace_src (from=0x403497c0, to=0x40175200, 
    insn=0x4034a2e0) at /work/src/vanilla.gcc/gcc/recog.c:754
#2  0x81d4128 in try_replace_reg (from=0x403497c0, to=0x40175200, 
    insn=0x4034a2e0) at /work/src/vanilla.gcc/gcc/gcse.c:3641
#3  0x81d4623 in cprop_insn (insn=0x4034a2e0, alter_jumps=0)
    at /work/src/vanilla.gcc/gcc/gcse.c:3881
#4  0x81d48b8 in cprop (alter_jumps=0) at /work/src/vanilla.gcc/gcc/gcse.c:3979
#5  0x81d49b1 in one_cprop_pass (pass=1, alter_jumps=0)
    at /work/src/vanilla.gcc/gcc/gcse.c:4018
#6  0x81cde3b in gcse_main (f=0x40347880, file=0x0)
    at /work/src/vanilla.gcc/gcc/gcse.c:739
#7  0x80b5c7b in rest_of_compilation (decl=0x40326e38)
    at /work/src/vanilla.gcc/gcc/toplev.c:3113
#8  0x806d1ef in c_expand_body (fndecl=0x40326e38, nested_p=0)
    at /work/src/vanilla.gcc/gcc/c-decl.c:6738
#9  0x806cec6 in finish_function (nested=0)
    at /work/src/vanilla.gcc/gcc/c-decl.c:6659
#10 0x804a684 in yyparse_1 () at c-parse.y:323
#11 0x80525ab in yyparse () at /work/src/vanilla.gcc/gcc/c-lex.c:157
#12 0x80b4373 in compile_file (
    name=0x84917a9 "/work/src/vanilla.gcc/gcc/libgcc2.c")
    at /work/src/vanilla.gcc/gcc/toplev.c:2354
#13 0x80b90c3 in main (argc=65, argv=0xbffff6c4)
    at /work/src/vanilla.gcc/gcc/toplev.c:4914

Unfortunately I don't see anything obviously relevant in the changes
to cprop_insn or cprop itself.

I am going to try backing out the changes in gcse.c and running a
bootstrap overnight, to see what happens.

zw