Re: PATCH: RFA reload.c patch

[Jim Wilson <wilson at specifixinc dot com>]

Eric Christopher wrote:
> Basically we weren't verifying that the addresses were valid in either
> case. For the first memory_operand isn't sufficient, and the last is
> that force_const_mem doesn't guarantee a valid address.

I sent my first reply to the wrong mailing list.

This patch doesn't make any sense to me.  If you search for 
reg_equiv_memory_loc at the top of reload1.c, you will find a comment 
that says it may not be a valid MEM, and that it goes into either 
reg_equiv_mem or reg_equiv_address depending on whether it is valid.

If you look about a hundred lines after the point that you patched, you 
will see code that does exactly what the comment says.  It passes 
reg_equiv_memory_loc through strict_memory_address_p, and puts it in 
reg_equiv_mem if valid, in reg_equiv_address if it looks like an address 
that reload can fix, and clears it otherwise.

So your patch that clears it earlier on if it doesn't pass 
memory_address_p doesn't make any sense.

Are you sure you aren't trying to cover up a bug in the frv port?  That 
what it looks like to me.

You didn't provide a testcase, and apparently can't because you can't 
reproduce this in FSF sources, which makes this even more suspect.

What later pass is assuming that addresses in reg_equiv_memory_loc are 
legitimate?
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com