This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Kazu recently made a change in auto-inc-dec.c to avoid using count_occurrences in one case, since it doesn't handle hard registers correctly. There was a patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00514.html which looks correct, but a different patch was checked in: @@ -1068,6 +1068,13 @@ find_inc (bool first_try) /* For the post_add to work, the result_reg of the inc must not be used in the mem insn since this will become the new index register. */ + if (count_occurrences (PATTERN (mem_insn.insn), inc_insn.reg_res, 1) == 0 + && reg_overlap_mentioned_p (inc_insn.reg_res, PATTERN (mem_insn.insn))) + { + debug_rtx (mem_insn.insn); + debug_rtx (inc_insn.reg_res); + gcc_unreachable (); + } if (count_occurrences (PATTERN (mem_insn.insn), inc_insn.reg_res, 1) != 0) { if (dump_file) which isn't actually fixing anything, just causing an abort when we encounter the problematic situation. This triggers on the PR44404 testcase if my ARM ldm/stm peephole patch is applied. I'll be checking in the below as obvious after some testing. There are some more calls to count_occurrences in auto-inc-dec.c which worry me a bit, but that's a problem for another day. Bernd
Attachment:
fix-ainc.diff
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |