This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[reload] paradoxical mems
- From: DJ Delorie <dj at redhat dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 12 Jan 2006 21:08:05 -0500
- Subject: [reload] paradoxical mems
reg_overlap_mentioned_for_reload_p() assumes that all SUBREGs
have REGs as their operand. However, register_operand() has
this comment:
(Ideally, (SUBREG (MEM)...) should not exist after reload,
but currently it does result from (SUBREG (REG)...) where the
reg went on the stack.) */
When this happens during reload, reg_overlap_mentioned_for_reload_p()
blindly takes the REGNO of a MEM and later on aborts. The patch below
at least treats (subreg (mem)) the same as (mem) for this function,
and gcc does the right thing later on anyway. The question is: does
finding a (subreg (mem)) at this point indicate that something is
wrong with my port (m32c)? Or is reload actually wrong here? If
reload is wrong, is this the right way to deal with these?
Index: reload.c
===================================================================
--- reload.c (revision 109647)
+++ reload.c (working copy)
@@ -6329,6 +6329,8 @@
/* If either argument is a constant, then modifying X can not affect IN. */
if (CONSTANT_P (x) || CONSTANT_P (in))
return 0;
+ else if (GET_CODE (x) == SUBREG && GET_CODE (SUBREG_REG (x)) == MEM)
+ return refers_to_mem_for_reload_p (in);
else if (GET_CODE (x) == SUBREG)
{
regno = REGNO (SUBREG_REG (x));