Jeff Law <l...@redhat.com> writes: > 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.
My first guess would be our current ooglie booglie: invalid stack slot sharing in cfgexpand.c. Ian
