Re: [PR64164] drop copyrename, integrate into expand

[Alexandre Oliva <aoliva@redhat.com>]

On Jun  9, 2015, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Jun  9, 2015, David Edelsohn <dje.gcc@gmail.com> wrote:
>> This also broke bootstrap on PPC64 LE Linux with the same error.

> Thanks for your reports.  I'm looking into the problem.

> I'd appreciate a preprocessed testcase from either of you to confirm the
> fix, if not to help debug it.

The first potential source for this problem that jumped at me would be
silenced with this change:

diff --git a/gcc/function.c b/gcc/function.c
index 8bcc352..9201ed9 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -2974,7 +2974,8 @@ assign_parm_setup_block (struct assign_parm_data_all *all,
 	stack_parm = copy_rtx (stack_parm);
       if (GET_MODE_SIZE (GET_MODE (entry_parm)) == size)
 	PUT_MODE (stack_parm, GET_MODE (entry_parm));
-      set_mem_attributes (stack_parm, parm, 1);
+      if (GET_CODE (stack_parm) == MEM)
+	set_mem_attributes (stack_parm, parm, 1);
     }
 
   /* If a BLKmode arrives in registers, copy it to a stack slot.  Handle

but I suspect there might be other similar issues lurking in function.c
after my attempt to turn parm assignment upside down ;-)

(namely, it used to assume it could pick stack slots and pseudos in a
whim, but after this change it must give way to out-of-SSA's partition
assignments.)

I'll look into cross-building some embedded targets and see if any
further issues surface.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer