This problem is found by code inspection. The comment of the generated file
insn-recog.c says:
`recog' contains a decision tree that recognizes whether the rtx
X0 is a valid instruction.
recog returns -1 if the rtx is not valid. If the rtx is valid, recog
returns a nonnegative number which is the insn code number for the
pattern that matched. This is the same as the order in the machine
description of the entry that matched. This number can be used as an
index into `insn_data' and other tables.
recog_memoized() is just a wrapper around recog() to cache results.
In recog.h:
/* Try recognizing the instruction INSN,
and return the code number that results.
Remember the code so that repeated calls do not
need to spend the time for actual rerecognition.
This function is the normal interface to instruction recognition.
The automatically-generated function `recog' is normally called
through this one. (The only exception is in combine.c.) */
static inline int
recog_memoized (rtx insn)
{
if (INSN_CODE (insn) < 0)
INSN_CODE (insn) = recog (PATTERN (insn), insn, 0);
return INSN_CODE (insn);
}
Yet in rs6000.c, there is code in rs6000_adjust_cost:
line 16312:
if (! recog_memoized (insn))
return 0;
line: 16355
&& recog_memoized (dep_insn)
&& (INSN_CODE (dep_insn) >= 0)
These look as if it is assumed that recog_memoized return 0 for invalid
instructions but 0 is a valid result code. The checks should be done against
negative return values instead.
--
Summary: possible bug in recog_memoized usage in rs6000.c??
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dkwan at transmeta dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28115
