This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
regrename.c RTL sharing bug
- From: Andrew Jenner <andrew at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Jan Hubicka <jh at suse dot cz>
- Date: Mon, 21 Apr 2008 11:59:05 -0700
- Subject: regrename.c RTL sharing bug
The gfortran.dg/ret_array_1.f90 and gfortran.dg/zero_sized_1.f90
testcases are failing to compile for ARM. This is because the rnreg
(regrename.c) pass is transforming a *arith_shiftsi_compare0 instruction
and causing the dup_loc[] entries to point to cc0, making the RTL invalid.
I have two possible patches to fix this, but I don't know which is the
better one. I have done a native bootstrap and test pass on both of
these any confirmed that neither introduces any additional failures.
The first patch simply prevents the RTL from being copied in the first
place. I think this is the correct patch if the "copy_rtx" call is
simply a vestige of some earlier change and is truly unneeded.
2008-04-14 Andrew Jenner <andrew@codesourcery.com>
gcc/
* regrename.c: Share RTX between match_operator and match_dup.
Index: gcc/regrename.c
===================================================================
--- gcc/regrename.c (revision 134414)
+++ gcc/regrename.c (working copy)
@@ -813,7 +813,7 @@ build_def_use (basic_block bb)
OP_IN, 0);
for (i = 0; i < recog_data.n_dups; i++)
- *recog_data.dup_loc[i] = copy_rtx (old_dups[i]);
+ *recog_data.dup_loc[i] = old_dups[i];
for (i = 0; i < n_ops; i++)
*recog_data.operand_loc[i] = old_operands[i];
if (recog_data.n_dups)
The second patch unshares the dup_loc RTL earlier, before the originals
are munged into cc0. I think this is the correct patch if there is still
a good reason why the RTX is being copied.
2008-04-14 Andrew Jenner <andrew@codesourcery.com>
gcc/
* regrename.c: Unshare RTX earlier in build_def_use to avoid
corruption of dup_loc.
Index: gcc/regrename.c
===================================================================
--- gcc/regrename.c (revision 134414)
+++ gcc/regrename.c (working copy)
@@ -783,6 +783,10 @@ build_def_use (basic_block bb)
recog_data.operand_type[i] = OP_INOUT;
}
+ /* Unshare dup_loc RTL */
+ for (i = 0; i < recog_data.n_dups; i++)
+ *recog_data.dup_loc[i] = copy_rtx(*recog_data.dup_loc[i]);
+
/* Step 1: Close chains for which we have overlapping reads. */
for (i = 0; i < n_ops; i++)
scan_rtx (insn, recog_data.operand_loc[i],
@@ -813,7 +817,7 @@ build_def_use (basic_block bb)
OP_IN, 0);
for (i = 0; i < recog_data.n_dups; i++)
- *recog_data.dup_loc[i] = copy_rtx (old_dups[i]);
+ *recog_data.dup_loc[i] = old_dups[i];
for (i = 0; i < n_ops; i++)
*recog_data.operand_loc[i] = old_operands[i];
if (recog_data.n_dups)
I found some previous patches relating to the same thing:
http://gcc.gnu.org/ml/gcc-patches/2002-03/msg01485.html
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01441.html
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01103.html
The symptoms in the first of these closely match what I am seeing, and
my patch undoes part of the second.
CCing Jan Hubicka, who has done some work in this area in the past. Jan
(or anyone) - do you have a preference between these two patches, or a
third suggestion?
Thanks,
--
Andrew Jenner
CodeSourcery
andrew@codesourcery.com
(650) 331-3385 x728