This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Bug in gen_recog.c?
- To: egcs-patches at egcs dot cygnus dot com
- Subject: Bug in gen_recog.c?
- From: Jan Hubicka <hubicka at atrey dot karlin dot mff dot cuni dot cz>
- Date: Fri, 23 Jul 1999 21:14:06 +0200
Hi
The problem with pattern I was discussing in egcs mailing list seems to be
caused by recog, namely not_both_true.
Basically there are patterns:
(something:HI (match_operand:HI "register_operand" "0))
and
(something:HI (subreg:HI (match_operand:QI "register_operand" "0) 0)
(in real version also:)
(something:HI (zero_extend:HI (match_operand:QI "register_operand" "0) 0)
The not_both_true seems to return 0 for first and second pattern, that is
obviously wrong. Generated tree then does weird thinks.
After poking around I think, it is caused by the fact, that match_operand
might consume subreg explicitly noted in the second. not_both_true don't seems
to be prepared for this eventuality and happily continues in checking
by recursibly verifing if match_operand:QI is not_both_true to match_operand:HI
and zero_extend:HI thats true, so it succeds.
My solution is to verify whether we are always verifying patterns on the
same positions in the insn. This seems to solve the bug, but I have no idea
how far from correct solution I am.
Honza
Fri Jul 23 15:17:00 EDT 1999 Jan Hubicka <hubicka@freesoft.cz>
* genrecog.c (not_both_true): Don't even try to compare strings on the
different positions in insn!
*** config/i386/genrecog.old Fri Jul 23 15:08:04 1999
--- genrecog.c Fri Jul 23 15:11:54 1999
*************** not_both_true (d1, d2, toplevel)
*** 672,677 ****
--- 672,681 ----
{
struct decision *p1, *p2;
+ /* Don't even try to compare strings on the different positions in insn! */
+ if (strcmp (d1->position, d2->position))
+ return 0;
+
/* If they are both to test modes and the modes are different, they aren't
both true. Similarly for codes, integer elements, and vector lengths. */