This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Committed: fix typo in ns32k.md (was: Re: instruction not recognized (genrecog bug?))
- To: hans-peter dot nilsson at axis dot com
- Subject: Committed: fix typo in ns32k.md (was: Re: instruction not recognized (genrecog bug?))
- From: Ian Dall <ian at beware dot dropbear dot id dot au>
- Date: Mon, 10 Jan 2000 23:02:58 +1030 (CST)
- Cc: ian at beware dot dropbear dot id dot au, gcc-patches at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org
- References: <14456.41217.851122.92754@sibyl.beware.dropbear.id.au><200001091621.RAA10058@ignucius.axis.se>
Hans-Peter Nilsson writes:
> > From: Ian Dall <ian@beware.dropbear.id.au>
> > Date: Mon, 10 Jan 2000 01:23:53 +1030 (CST)
>
> > The interesting thing is that this seems to me like a bug in genrecog.c
> > There is an insn in the ns32k.md which should match as far as I can see:
> >
> > (define_insn ""
> > [(set (match_operand:SI 0 "general_operand" "=g<")
> > (match_operand:QI 1 "address_operand" "p"))]
>
> No, there's a typo in that pattern; operands 0 and 1 must have
> the same mode. Since the typo is IMHO obvious, I installed this
> patch [changed QI to SI]
I thought that for an address_operand the mode referred to the object
pointed to, not the pointer, which is why I didn't just change it
myself. On some architectures, there could be alignment restrictions
on a pointer to single integer couldn't there be? Of course, for the
ns32k, that restriction doesn't apply so maybe it is academic, but there\
seems to be code in genrecog.c to handle address operands specially.
Ian