Re: Committed: fix typo in ns32k.md (was: Re: instruction not recognized (genrecog bug?))

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

> From: Ian Dall <ian@beware.dropbear.id.au>
> Date: Mon, 10 Jan 2000 23:02:58 +1030 (CST)

(Follow-ups should perhaps drop gcc-patches or gcc-bugs)

> 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.

*Oh no*!
You're perfectly right.  The address_operand predicate gets an
ugly exception for the match-operands-modes-unless-VOIDmode rule
in patterns.  Line 190:ish in md.texi,
<URL:http://gcc.gnu.org/onlinedocs/gcc_16.html>, and around
line 596 in genrecog.c among other clues.  So much for my
ability to recognize obviousness in this area.

In my defense I can only say that things did not get worse; as
long as a bootstrap fails in the manner you described, there is
a fatal bug for ns32k.  This change might have covered it up,
but that's all.  From Ian:s analysis, the typo theory did fit,
but I certainly did not do my homework before committing.
 Whether the real bug is in genrecog.c (like an inability to
generate a special-case for address_operand in the generated
insn-recog.c - my guess), the ns32k port (missing pattern) or
elsewhere (reload?), is a question that still remains.  I'll try
to find the right solution.

I'm terribly sorry.  I think I should just keep from committing
"obvious" things.

All in all, the ns32k port has not aged gracefully with the rest
of GCC.

brgds, H-P