On Thu, Aug 20, 2009 at 3:37 PM, Jeff Law<l...@redhat.com> wrote: > On 08/20/09 02:45, Richard Guenther wrote: >> >> It looks indeed bogus. Do you have a testcase at hand? >> > > Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu. Find > MAIN__.omp_fn.2 in the .expand dump. > > Within that function, you're looking for this sequence of insns: > > > > ;; D.3137_29 = REALPART_EXPR <.omp_data_i_55(D)->c>; > > (insn 242 241 0 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 0 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)) > > > This doesn't cause a libgomp testsuite failure in the mainline because > (reg:SF 74) gets a hard reg and thus reload doesn't utilize the bogus > REG_EQUIV note that eventually gets added to insn 242.
I suppose we are using the complex type alias-set at one place and the component at another. My suggestion would be to handle complex types like we do array and vector tyoes in get_alias_set, thus assign the component alias set to the complex types. Richard. > Jeff >
