I've been experimenting with a patch that adds a new define_peephole2
for MIPS. It was blowing up with a segfault in insn-recog.c while
building libstdc++, and looking at the generated code for my new pattern
there was clearly a bad offset being passed to peep2_next_insn. I
tracked it down to a regression from r174305, Richard's patch to add a
new data structure to keep track of positions in genrecog.c. Looks like
a think-o in the code that accounts for filtering out match_scratch and
match_dup in the input pattern; and for added fun, the caching of
position chains was making it produce incorrect code for a
define_peephole2 that doesn't even involve those things. :-P (In fact,
it's the existing "Same as above, except LO is the initial target of the
macc" pattern in mips.md that was initially being mis-counted.)
Is this patch OK to check in? I tested it by diffing the generated
insn-recog.c for a mips-sde-elf build against one I got using a
pre-r174305 genrecog.c.
-Sandra
2011-07-18 Sandra Loosemore <san...@codesourcery.com>
gcc/
* genrecog.c (make_insn_sequence): Correct position numbering
when filtering out match_scratch and match_dup.
Index: genrecog.c
===================================================================
--- genrecog.c (revision 176433)
+++ genrecog.c (working copy)
@@ -2345,7 +2345,7 @@ make_insn_sequence (rtx insn, enum routi
if (GET_CODE (tmp) != MATCH_SCRATCH && GET_CODE (tmp) != MATCH_DUP)
{
c_test_pos = next_position (pos_ptr, &root_pos,
- POS_PEEP2_INSN, i);
+ POS_PEEP2_INSN, j);
XVECEXP (x, 0, j) = tmp;
j++;
pos_ptr = &c_test_pos->next;
