Is this use of rtx_addr_varies_p an aliasing bug?

[Nigel Stephens]

I've been reviewing some patches which I'd made to gcc-2.95, for 
possible merging into 3.4 and 3.5, and I've come across a bug fix which 
still appears to apply - in fact more so in 3.x, since this idiom is now 
used more frequently.

What I see is several calls to true_dependence and canon_true_dependence 
passing a pointer to function rtx_addr_varies_p as their VARIES 
argument, for example in gcse.c:

  if (true_dependence (dest, GET_MODE (dest), gcse_mem_operand,
               rtx_addr_varies_p))
    gcse_mems_conflict_p = 1;

Walking through true_dependence, and then 
fixed_scalar_and_varying_struct_p, the expression which ultimately gets 
passed to the VARIES function is not the original MEM, but the address 
of the MEM, e.g.

  if (MEM_SCALAR_P (mem1) && MEM_IN_STRUCT_P (mem2)
      && !varies_p (mem1_addr, 1) && varies_p (mem2_addr, 1))
    /* MEM1 is a scalar at a fixed address; MEM2 is a struct at a
       varying address.  */
    return mem1;

But then looking at rtx_addr_varies_p, the only thing which can make it 
return true is if it finds a MEM whose address varies (rtx_varies_p). 
This seems to be wrong because it will never (except on some CISC 
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?

Regards

Nigel