This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
unexpected insn sign extension
- To: gcc at gcc dot gnu dot org
- Subject: unexpected insn sign extension
- From: " J S Hammond" <jshammond at my-Deja dot com>
- Date: Fri, 02 Jun 2000 17:24:44 -0700
- Organization: My Deja Email (http://www.my-deja.com:80)
- Reply-To: jshammond at my-Deja dot com
I have the following piece of code
main()
{
short a,b;
a = 2;
b = a * ((short)101);
}
When I compile it using my gcc cross compiler
I get the following error message
test.c: In function `main':
test.c:7: internal error--unrecognizable insn:
(insn 14 13 16 (set (reg:HI 21)
(mult:HI (sign_extend:HI (reg:QI 22))
(sign_extend:HI (const_int 101)))) -1 (nil)
(nil))
/cygwincore/gcc/toplev.c:1360: Internal compiler error in function fatal_insn
My first question is why would my multiply
try to sign extend the QI arguments to HI mode
when everything is in QI mode?
If I use another short variable instead of
the typecast constant I get a multiply
statement that uses the QI mode multiply
(mulqi3).
I have defined mulqihi3 like so,
(define_insn "mulqihi3"
[(set (match_operand:HI 0 "register_operand" "=r,r")
(mult:HI (sign_extend:HI (match_operand:QI 1 "register_operand" "%0,0"))
(sign_extend:HI (match_operand:QI 2 "general_operand" "r,i"))))]
""
"@
mr r%0,r%2 ; mulqihi3 - case 0(1)
mim r%0,%2 ; mulqihi3 - case 1(1)")
My second question is why doesn't the
unrecognized insn match case 1 of mulqihi3?
I can see that operands 0 & 1 are not the same
in my unregcnized insn like my mulqihi3 has,
but doesn't the comipler usually find a way around this?
Any help appreciated,
Jeff Hammond
--== Sent via Deja.com http://www.deja.com/ ==--
Before you buy.