Re: Latent bug in update_equiv_regs?

[Jeff Law <law at redhat dot com>]

On 08/19/09 17:46, Ian Lance Taylor wrote:
> My understanding is that that scenario is supposed to not happen because
> update_equiv_regs is only supposed to equate a register and a memory
> location in the specific cases where that is OK.  It's not no_equiv that
> is supposed to fix this, the equivalence should only be created when it
> will always be OK.
>
> So I think you need to explain more about why the equivalence was
> created.
>
> Ian
>    
You're right.  This should have been rejected by validate_equiv_mem, but 
isn't because the two memory references are in different alias sets.

You can see this in the mainline sources configured for 
i686-pc-linux-gnu by compiling 
libgomp/testsuite/libgomp.fortran/reduction1.f90 with -O3 -fopenmp

In the .expand dump we have:

(insn 242 241 243 47 j.f90:138 (set (reg:SF 74 [ D.3137 ])
        (mem/s:SF (plus:SI (reg/f:SI 247 [ .omp_data_i ])
                (const_int 32 [0x20])) [2 .omp_data_i_55(D)->c+0 S4 
A64])) -1 (nil))
[ ... ]

(insn 247 246 248 47 j.f90:138 (set (mem/s:SF (plus:SI (reg/f:SI 247 [ 
.omp_data_i ])
                (const_int 32 [0x20])) [13 S4 A64])
        (reg:SF 351)) -1 (nil))

As you can see we've got different alias sets on the two MEMs.   This 
could be an expansion bug, f95 bug, or a bug in one of the SSA 
optimizers.   Ugh.

Thanks,
jeff