This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH 2/9] Fix reloads_unique_chain_p() missing a conflict
- From: Rask Ingemann Lambertsen <rask at sygehus dot dk>
- To: gcc-patches at gcc dot gnu dot org
- Date: Mon, 30 Jul 2007 16:37:45 +0200
- Subject: [PATCH 2/9] Fix reloads_unique_chain_p() missing a conflict
- References: <20070730134217.GK25795@sygehus.dk>
As discussed starting with this message
<URL:http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01343.html>, it is
possible for reloads_unique_chain() to miss a reload conflict. It happens
when two reloads are in a different other than expected. Reloads are sorted
using target specific information and besides, the sorting is performed by
qsort() which isn't guaranteed to be stable. The fix here is to check both
reloads passed to reloads_unique_chain_p().
This and the other two reload patches in this patch set were bootstrapped
and tested together on x86_64-unknown-linux-gnu with no new failures. I also
built and tested cross compilers for arm-unknown-elf, cris-axis-elf,
m32c-unknown-elf, mipsisa64-unknown-elf, sh-unknown-elf and v850-unknown-elf
with no new failures.
Ok for trunk?
2007-07-30 Rask Ingemann Lambertsen <rask@sygehus.dk>
* reload1.c (reloads_unique_chain_p): Check both reloads.
Index: gcc/reload1.c
===================================================================
--- gcc/reload1.c (revision 126653)
+++ gcc/reload1.c (working copy)
@@ -4960,7 +4976,8 @@ reloads_unique_chain_p (int r1, int r2)
if (i != r1 && i != r2 && rld[i].in)
{
/* If our reload is mentioned at all, it isn't a simple chain. */
- if (reg_mentioned_p (rld[r1].in, rld[i].in))
+ if (reg_mentioned_p (rld[r1].in, rld[i].in)
+ || reg_mentioned_p (rld[r2].in, rld[i].in))
return false;
}
return true;
--
Rask Ingemann Lambertsen