On Thu, Aug 20, 2009 at 2:33 AM, Jeff Law<l...@redhat.com> wrote: > 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.
It looks indeed bogus. Do you have a testcase at hand? Richard. > Thanks, > jeff > > > >
