[Bug target/46088] [4.6 Regression] ICE: SIGSEGV in ix86_binary_operator_ok (i386.c:15025) with -Os -fnon-call-exceptions -fpeel-loops

["ebotcazou at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46088

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2010-11-11 11:27:27 UTC ---
> The insn that was matched looks like:
> 
> (gdb) up
> #1  0x0000000000b9da94 in recog_7 (x0=0x7ffff1f329d8, insn=0x7ffff1f296c0, 
>     pnum_clobbers=0x7fffffffdc9c)
>     at ../../gcc-svn/trunk/gcc/config/i386/i386.md:10089
> 10089       && ix86_binary_operator_ok (<CODE>, <MODE>mode, operands)"
> (gdb) p debug_rtx (insn)
> (insn 7 6 8 2 (set (reg:CCZ 17 flags)
>         (compare:CCZ (lshiftrt:SI (reg/v:SI 60 [ i ])
>                 (const_int 3 [0x3]))
>             (const_int 0 [0]))) pr46088.c:5 2 {*cmpsi_ccno_1}
>      (nil))
> $1 = void
> 
> So, clobber of the scratch reg is missing, but the insn is recognized as
> *lshrsi3_cconly anyway.

Yes, this is the documented behavior of the combiner so back-ends need to cope
with it.  A possible approach would be to define a specialized version of
ix86_binary_operator_ok, e.g. ix86_binary_operator_ok_for_reg_dest, and uses it
in any pattern that has match_scratch as destination.  The existing logic in
ix86_binary_operator_ok can avoid reading DST if it knows it's a REG.