This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Bug in sh constant pool generation
- To: gcc-patches at gcc dot gnu dot org
- Subject: Bug in sh constant pool generation
- From: Bernd Schmidt <bernds at redhat dot co dot uk>
- Date: Sat, 16 Sep 2000 12:52:49 +0100 (BST)
Large constants on the sh are placed in small in-line constant pools which
are accessed through pc-relative addressing. This happens during
machine_dependent_reorg. We walk the insns looking for constant moves that
need to be converted to pc-relative loads. When placing the constant pools,
we need to ensure that the offset from the load to the pool is within the
insn's range.
There's a problem with this code; in machine_dependent_reorg we sometimes
generate new insns, but we do not take this into account when computing the
offsets in find_barrier. Thus we can end up with out-of-range accesses.
Bernd
* sh.c (find_barrier): Take into account that machine_dependent_reorg
might add new insns.
Index: config/sh/sh.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/config/sh/sh.c,v
retrieving revision 1.171
diff -u -p -r1.171 sh.c
--- sh.c 2000/09/14 06:13:15 1.171
+++ sh.c 2000/09/16 11:48:29
@@ -2199,6 +2199,14 @@ find_barrier (num_mova, mova, from)
if (num_mova)
si_limit -= GET_MODE_SIZE (mode);
}
+
+ /* See the code in machine_dependent_reorg, which has a similar if
+ statement that generates new mova insn in many cases. */
+ if (GET_CODE (dst) == REG
+ && ((REGNO (dst) >= FIRST_FP_REG
+ && REGNO (dst) <= LAST_XD_REG)
+ || REGNO (dst) == FPUL_REG))
+ inc += 2;
}
if (mova_p (from))