Is this use of rtx_addr_varies_p an aliasing bug?

[Jim Wilson]

Nigel Stephens wrote:
> architectures I guess) be passed the enclosing MEM. My hunch is that all 
> current uses of rtx_addr_varies_p should be replaced by rtx_varies_p, 
> and rtx_addr_varies_p should then be removed. Does that make sense, or 
> have I missed something?

gcc-bugs is not a very good place for questions like this.  gcc-bugs is 
primarily used for output from the bugzilla bug database.  You are 
better off sending questions like this to the gcc list.

Yes, this all makes sense.  This looks like it has been broken ever 
since the  fixed_scalar_and_varying_struct_p function was first created, 
which was in between the 2.8 and 2.95 releases.

rtx_addr_varies_p does do one more thing than rtx_varies_p.  It returns 
true if passed a BLKmode MEM.  I wonder if this explains why we have 
been having all sorts of BLKmode related problems with MEM_IN_STRUCT_P 
in the gcc-3.4 release process.  Perhaps some of them would go away if 
we re-added the BLKmode test.

At this point though, we have been clearly operating without the BLKmode 
test for over 5 years, so there is no overriding need to keep it.

I think it looks right to replace all current uses of rtx_addr_varies_p 
with rtx_varies_p.  This might expose optimizer issues though, since it 
will make the MEM_IN_STRUCT_P optimizations work in cases where they 
have been accidentally disabled for 5 years, so we will have to be 
careful about that.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com