This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Fix a reload problem on powerpc64-linux
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sat, 31 Aug 2002 21:58:59 +0930
- Subject: Fix a reload problem on powerpc64-linux
Is this a reasonable thing to do?
* reload.c (find_reloads <p constraint>): Pass operand_mode to
find_reloads_address.
Index: gcc/reload.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.178.2.4
diff -u -p -r1.178.2.4 reload.c
--- gcc/reload.c 13 Jun 2002 16:08:12 -0000 1.178.2.4
+++ gcc/reload.c 31 Aug 2002 11:44:03 -0000
@@ -2643,7 +2643,7 @@ find_reloads (insn, replace, ind_levels,
;
else if (constraints[i][0] == 'p')
{
- find_reloads_address (VOIDmode, (rtx*) 0,
+ find_reloads_address (recog_data.operand_mode[i], (rtx*) 0,
recog_data.operand[i],
recog_data.operand_loc[i],
i, operand_type[i], ind_levels, insn);
The background to the patch is that the builtin-prefetch-2.c test has
been failing lately like this:
GNU C version 3.2.1 20020830 (prerelease) (powerpc64-linux)
compiled by GNU C version 2.95.4 20011006 (Debian prerelease).
Program received signal SIGSEGV, Segmentation fault.
0x10264278 in build_def_use (bb=0x103b3660) at /src/gcc-3.2/gcc/regrename.c:803
(gdb) p debug_rtx (insn)
(insn 341 335 565 (prefetch (plus:DI (reg/f:DI 1 r1)
(const_int 520 [0x208]))
(const_int 0 [0x0])
(const_int 0 [0x0])) 530 {prefetch} (nil)
(nil))
OK, so we got a stack slot, which isn't valid for this particular insn.
A little debugging reveals that the constrain_operands call a few lines
earlier is failing (it really should have an abort), because:
- the rs6000 prefetch insn has operand[0] as V4SImode, with a 'p' constraint
- strict_memory_address_p calls rs6000_legitimate_address
- rs6000.h:LEGITIMATE_OFFSET_ADDRESS_P tests ALTIVEC_VECTOR_MODE (MODE)
which is true for V4SImode, false for VOIDmode, and only allows a zero
offset for V4SImode.
This insn should have been fixed earlier by reload, but since VOIDmode
was passed down to find_reloads_address, the call to
strict_memory_address_p there returned true, convincing reload that
the address was OK. Hence the patch. But I won't be at all surprised
to be told I don't know what I'm doing.
--
Alan Modra
IBM OzLabs - Linux Technology Centre