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
