RE: Crazy ICE from gcc 4.1.0

[Meissner, Michael]

I suspect it isn't matching pattern #2, because it couldn't get a QI
register, and instead it falls back to the general case of moving to a
normal register.  I believe the gcc_assert should contain a check for
CONST_INT as well as a QI register or memory.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Alan Lehotsky
Sent: Thursday, March 09, 2006 1:05 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Crazy ICE from gcc 4.1.0

I've built a generic 4.1.0 for RH7.3 x86 linux (I did a make bootstrap)

Compiling a rather large file, I get 

tmp.f_000000.cxx:26432: error: unrecognizable insn:
(insn 173 172 174 9 (set (reg:QI 122)
        (const_int 128 [0x80])) -1 (nil)
    (nil))
tmp.f_000000.cxx:26432: internal compiler error: in extract_insn, at
recog.c:2020


Which looks insane, because there's a perfectly good define_insn (cf
*movqi_1" in i386.md)
I'm trying to reduce this to a reasonably sized test case (and I'm going
to try debugging this in the recognizer),
but I can't see why this instruction isn't matching the 2nd constraint
alternative and just producing a "movb r,#128"


(define_insn "*movqi_1"
  [(set (match_operand:QI 0 "nonimmediate_operand" "=q,q ,q ,r,r ,?r,m")
        (match_operand:QI 1 "general_operand"      "
q,qn,qm,q,rn,qm,qn"))]
  "GET_CODE (operands[0]) != MEM || GET_CODE (operands[1]) != MEM"
{
  switch (get_attr_type (insn))
    {
    case TYPE_IMOVX:
      gcc_assert (ANY_QI_REG_P (operands[1]) || GET_CODE (operands[1])
== MEM);
      return "movz{bl|x}\t{%1, %k0|%k0, %1}";
    default:
      if (get_attr_mode (insn) == MODE_SI)
        return "mov{l}\t{%k1, %k0|%k0, %k1}";
      else
        return "mov{b}\t{%1, %0|%0, %1}";
    }
}